# Tidsresa i arbetsflöden

Queuety kan spola tillbaka ett arbetsflöde till ett tidigare steg och återuppta körningen därifrån. Det är användbart när ett steg gav felaktiga resultat, när du vill försöka igen med en annan konfiguration eller när du behöver återställa skadade data utan att starta om hela arbetsflödet.

Återspolning bygger på [Arbetsflödets händelselogg](https://queuety.inline0.dev/sv/docs/workflows/event-log). Händelseloggen måste ha `state_after` data för målsteget.

## Spola tillbaka ett arbetsflöde

### PHP API

Anropa `Queuety::rewind_workflow()` med arbetsflödets ID och stegindexet att spola tillbaka till:

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

Parametern `to_step` är det nollbaserade indexet för steget vars slutförda tillstånd ska återställas. Körningen fortsätter från _nästa_ steg (to_step + 1).

### CLI

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

| Alternativ | Beskrivning |
|---|---|
| `<id>` | Arbetsflödes-ID (krävs) |
| `<step>` | Stegindex att spola tillbaka till, börjar vid 0 (krävs) |

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

## Så fungerar det

När du spolar tillbaka ett arbetsflöde till steg N:

1. Händelseloggen frågas efter värdet `state_after` som registrerades efter att steg N slutfördes
2. Om ingen ögonblicksbild finns utlöses ett `RuntimeException`
3. Arbetsflödesraden låses
4. Arbetsflödestillståndet ersätts med ögonblicksbilden, samtidigt som alla reserverade nycklar (`_steps`, `_queue`, `_priority` osv.) från den aktuella arbetsflödesraden bevaras
5. `current_step` sätts till N + 1 och `status` sätts till `running`
6. Fälten `error_message` och `failed_at` rensas
7. Steget vid index N + 1 läggs i kö för bearbetning
8. En `workflow_rewound`-logghändelse registreras

Arbetaren hämtar sedan det kölagda steget, och arbetsflödet fortsätter som vanligt därifrån.

## Krav

Återspolning kräver data `state_after` i händelseloggen. Händelseloggen registrerar dem automatiskt för varje `step_completed`-händelse. Om händelseloggen har rensats (via `WorkflowEventLog::prune()`) och tillståndet för målsteget inte längre finns kvar misslyckas återspolningen.

Se till att händelseloggens lagringstid täcker den period du kan behöva återspola till.

## Användningsområden

### Åtgärda en felaktig steghanterare

Om en steghanterare hade ett fel som gav felaktiga utdata kan du distribuera korrigeringen och återspola:

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

### Försök igen med en annan konfiguration

När ett steg misslyckades på grund av externa faktorer (API-hastighetsbegränsning, felaktiga autentiseringsuppgifter) korrigerar du konfigurationen och återspolar för att köra steget 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 );
```

### Återställning från felaktiga data

Om ett tidigare steg lade in felaktiga data i tillståndet återspolar du till en känd, korrekt ögonblicksbild:

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

## Jämförelse med omförsök

| Aspekt | `retry_workflow()` | `rewind_workflow()` |
|---|---|---|
| Återupptas från | Det misslyckade steget | Valfritt tidigare steg |
| Tillstånd | Aktuellt arbetsflödestillstånd | Återställt från händelseloggen `state_after` |
| Kräver | Arbetsflödet har statusen `failed` | Ögonblicksbild i händelseloggen vid målsteget |
| Status efteråt | `running` | `running` |
| Logghändelse | ingen | `workflow_rewound` |