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. 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:

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

wp queuety workflow rewind <id> <step>

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:

// 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:

// 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:

// 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