# Пътуване във времето в работен процес

Queuety може да върне работния процес към предишна стъпка и да възобнови изпълнението оттам. Това е полезно, ако стъпка е произвела грешен резултат, ако искате да опитате отново с различна конфигурация или ако трябва да възстановите повредени данни, без да стартирате целия работен процес отначало.

Връщането назад разчита на [журнала на събитията на работния процес](https://queuety.inline0.dev/bg/docs/workflows/event-log). Журналът на събитията трябва да съдържа данни `state_after` за целевата стъпка.

## Връщане на работен процес назад

### PHP API

Извикайте `Queuety::rewind_workflow()` с ID на работния процес и индекса на стъпката, към която да се върнете:

```php
use Queuety\Queuety;

// Rewind workflow 42 to step 1.
// The state is restored to the snapshot taken after step 1 completed,
// and step 2 is enqueued for re-execution.
Queuety::rewind_workflow( $workflow_id, to_step: 1 );
```

Параметърът `to_step` е индексът, започващ от нула, на стъпката, чието завършено състояние трябва да бъде възстановено. Изпълнението продължава от _следващата_ стъпка (to_step + 1).

### CLI

```bash
wp queuety workflow rewind <id> <step>
```

| Опция | Описание |
|---|---|
| `<id>` | ИД на работен поток (задължително) |
| `<step>` | Индекс на стъпката, към която да се върне потокът, започващ от 0 (задължително) |

```bash
wp queuety workflow rewind 42 1
```

## Как работи

Когато върнете работния процес към стъпка N:

1. В журнала на събитията се търси стойността `state_after`, записана след завършването на стъпка N
2. Ако няма моментна снимка, се хвърля `RuntimeException`
3. Редът на работния процес се заключва
4. Състоянието на работния процес се заменя с моментната снимка, като се запазват всички запазени ключове (`_steps`, `_queue`, `_priority` и др.) от текущия ред на работния процес
5. `current_step` се задава на N + 1, а `status` се задава на `running`
6. Всички полета `error_message` и `failed_at` се изчистват
7. Стъпката с индекс N + 1 се добавя на опашката за обработка
8. Записва се събитие `workflow_rewound` в журнала

След това работникът поема добавената на опашката стъпка и работният процес продължава нормално оттам нататък.

## Изисквания

За връщане назад са необходими данни `state_after` в журнала на събитията. Журналът ги записва автоматично за всяко събитие `step_completed`. Ако журналът е бил съкратен (чрез `WorkflowEventLog::prune()`) и състоянието за целевата стъпка вече не съществува, връщането назад ще е неуспешно.

Уверете се, че периодът на съхранение на журнала на събитията покрива времето, до което може да се наложи да се върнете.

## Случаи на употреба

### Поправяне на проблемен обработчик на стъпка

Ако обработчикът на стъпка е имал грешка, довела до неправилен резултат, можете да внедрите поправката и да върнете работния процес назад:

```php
// Step 2 (CallLLMHandler) produced garbled output due to a prompt bug.
// After fixing CallLLMHandler, rewind to step 1 so step 2 runs again
// with the corrected handler.
Queuety::rewind_workflow( $workflow_id, to_step: 1 );
```

### Повторен опит с различна конфигурация

Ако стъпка се е провалила поради външни фактори (ограничение на заявките към API, невалидни идентификационни данни), поправете конфигурацията и се върнете назад, за да опитате отново:

```php
// Step 3 failed because the API key was expired.
// After updating the key, rewind to step 2 so step 3 retries.
Queuety::rewind_workflow( $workflow_id, to_step: 2 );
```

### Възстановяване след невалидни данни

Ако по-ранна стъпка е въвела невалидни данни в състоянието, върнете се към известна добра моментна снимка:

```php
// Step 0 fetched correct data, but step 1 corrupted it.
// Rewind to step 0 to restore the good state and re-run step 1.
Queuety::rewind_workflow( $workflow_id, to_step: 0 );
```

## Сравнение с повторен опит

| Аспект | `retry_workflow()` | `rewind_workflow()` |
|---|---|---|
| Продължава от | Неуспешната стъпка | Всяка предишна стъпка |
| Състояние | Текущото състояние на работния процес | Възстановено от моментна снимка в журнала на събитията `state_after` |
| Изисква | Работният процес е в състояние `failed` | Моментна снимка в журнала на събитията за целевата стъпка |
| Състояние след това | `running` | `running` |
| Събитие в журнала | няма | `workflow_rewound` |