# Tidsrejse i workflows

Queuety kan spole et workflow tilbage til et tidligere trin og genoptage kørslen derfra. Det er nyttigt, når et trin har produceret et forkert resultat, når du vil prøve igen med en anden konfiguration, eller når du skal gendanne efter korrupte data uden at genstarte hele workflowet.

Tilbagespoling afhænger af [Workflow-hændelsesloggen](https://queuety.inline0.dev/da/docs/workflows/event-log). Hændelsesloggen skal have `state_after` data for måltrinnet.

## Tilbagespoling af et workflow

### PHP API

Kald `Queuety::rewind_workflow()` med workflow-id'et og trinnets indeks, du vil spole tilbage til:

```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 );
```

Parameteren `to_step` er det nulbaserede indeks for det trin, hvis afsluttede tilstand skal gendannes. Kørselen genoptages fra det _næste_ trin (to_step + 1).

### CLI

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

| Valgmulighed | Beskrivelse |
|---|---|
| `<id>` | Workflow-id (påkrævet) |
| `<step>` | Trinindeks, der skal spoles tilbage til, 0-baseret (påkrævet) |

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

## Sådan fungerer det

Når du spoler et workflow tilbage til trin N:

1. Hændelsesloggen forespørges efter værdien `state_after`, der blev registreret efter afslutningen af trin N
2. Hvis der ikke findes et snapshot, udløses en `RuntimeException`
3. Workflowrækken låses
4. Workflowtilstanden erstattes med snapshottet, mens alle reserverede nøgler (`_steps`, `_queue`, `_priority` osv.) fra den aktuelle workflowrække bevares
5. `current_step` sættes til N + 1, og `status` sættes til `running`
6. Eventuelle felter for `error_message` og `failed_at` ryddes
7. Trinnet ved indeks N + 1 sættes i kø til behandling
8. En `workflow_rewound`-loghændelse registreres

Workeren henter derefter trinnet fra køen, og workflowet fortsætter som normalt derfra.

## Krav

Tilbagespoling kræver `state_after`-data i hændelsesloggen. Hændelsesloggen registrerer dem automatisk for hver `step_completed`-hændelse. Hvis hændelsesloggen er blevet beskåret (via `WorkflowEventLog::prune()`), og tilstanden for måltrinnet ikke længere findes, mislykkes tilbagespolingen.

Sørg for, at opbevaringsperioden for hændelsesloggen dækker den periode, du muligvis skal spole tilbage til.

## Anvendelsesområder

### Ret en fejlbehæftet trinhandler

Hvis en trinhandler havde en fejl, der gav et forkert resultat, kan du implementere rettelsen og spole tilbage:

```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 );
```

### Prøv igen med en anden konfiguration

Når et trin fejlede på grund af eksterne forhold (API-hastighedsbegrænsning, ugyldige legitimationsoplysninger), skal du rette konfigurationen og spole tilbage for at køre det igen:

```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 );
```

### Gendan efter forkerte data

Hvis et tidligere trin indsatte forkerte data i tilstanden, skal du spole tilbage til et kendt korrekt snapshot:

```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 );
```

## Sammenligning med nyt forsøg

| Egenskab | `retry_workflow()` | `rewind_workflow()` |
|---|---|---|
| Genoptager fra | Det fejlede trin | Et vilkårligt tidligere trin |
| Tilstand | Aktuel workflowtilstand | Gendannet fra hændelsesloggens `state_after` |
| Kræver | Workflowet har status `failed` | Snapshot af hændelsesloggen ved måltrinnet |
| Status bagefter | `running` | `running` |
| Loghændelse | ingen | `workflow_rewound` |