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

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

wp queuety workflow rewind <id> <step>

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:

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

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

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