Schutzmaßnahmen für Workflows

Agentenähnliche Workflows sind flexibel, doch dadurch entstehen auch leichter doppelte Ausführungen oder ein Planer erzeugt mehr Arbeit als vorgesehen. Queuety bietet einfache Schutzmaßnahmen auf Workflow-Ebene, damit du flexibel bleibst und zugleich die Kontrolle behältst.

Das umfassendere Ressourcenmodell für die Zulassung von Workern und Kostenmetadaten pro Auftrag findest du unter Ressourcenverwaltung.

Eine Workflow-Definition versionieren

Verwende version(), um einer Workflow-Definition eine Versionsbezeichnung auf Anwendungsebene zuzuweisen:

Queuety::workflow( 'research_run' )
    ->version( 'research.v2' )
    ->then( PlanResearchStep::class )
    ->then( DraftResearchSummaryStep::class )
    ->dispatch();

Die Version wird mit dem Workflow-Status gespeichert, über workflow_status() bereitgestellt, von wp queuety workflow status ausgegeben und in Workflow-Exporte aufgenommen.

Queuety speichert außerdem für jede Workflow-Ausführung einen deterministischen definition_hash. Der Hash wird aus der serialisierten Workflow-Definition abgeleitet und hilft dir, nach einer Bereitstellung genau zu bestimmen, welche Workflow-Struktur eine laufende Ausführung verwendet.

Ausführung idempotent machen

Verwende idempotency_key(), wenn Aufrufer dieselbe Anfrage wiederholen können:

Queuety::workflow( 'research_run' )
    ->idempotency_key( 'brief:42:research' )
    ->then( PlanResearchStep::class )
    ->dispatch( [ 'brief_id' => 42 ] );

Wird ein Workflow erneut mit einem bereits verwendeten Schlüssel gestartet, gibt Queuety die ursprüngliche Workflow-ID zurück, statt eine doppelte Ausführung anzulegen. Schlüssel gelten global über alle Workflow-Namen hinweg. Nimm daher den Workflow-Namen in den Schlüssel auf, wenn verschiedene Workflows denselben Schlüssel verwenden könnten.

Das ist besonders nützlich für:

• API-Endpunkte, deren Anfragen von Clients oder Gateways wiederholt werden können
• Webhook-Verbraucher, die doppelte Zustellungen erhalten können
• Planerschritte, die pro externer Entität nur eine Orchestrierungsausführung anlegen sollen

Idempotenzschlüssel werden in der Tabelle queuety_workflow_dispatch_keys gespeichert.

Workflow-Limits festlegen

Verwende Workflow-Limits, damit Ausführungen fehlschlagen, sobald sie den vorgesehenen Rahmen überschreiten:

Queuety::workflow( 'research_run' )
    ->max_transitions( 20 )
    ->max_for_each_items( 12 )
    ->max_state_bytes( 32768 )
    ->max_cost_units( 40 )
    ->max_started_workflows( 8 )
    ->then( PlanResearchStep::class )
    ->for_each( 'tasks', ExecuteResearchTask::class, 'results' )
    ->dispatch();

max_transitions()

Begrenzt, wie viele Workflow-Schritte abgeschlossen werden dürfen, bevor die Ausführung fehlschlägt. Das schützt Workflows, die dynamisch verzweigen oder über _next_step denselben Bereich erneut durchlaufen können.

max_for_each_items()

Begrenzt, wie viele zur Laufzeit ermittelte Elemente ein einzelner Schritt for_each() entfalten darf. Das ist nützlich für Planer-Ausführer-Systeme, in denen ein Agent deutlich mehr Zweigarbeit entdecken könnte als vorgesehen.

max_state_bytes()

Begrenzt die codierte Größe des öffentlichen Workflow-Status. So wird verhindert, dass lang laufende Workflows zu großen Datenblöcken anwachsen, die sich nur langsam prüfen, exportieren oder erneut ausführen lassen.

max_cost_units()

Begrenzt die gesamten Kosteneinheiten, die durch abgeschlossene Schritte verbraucht werden. Die Kosteneinheiten stammen aus den Schritt- oder Auftragsmetadaten, die Queuety beim Einreihen von Arbeit auflöst. Reguläre Nutzerarbeit hat standardmäßig den Wert 1, Orchestrierungs-Platzhalter wie Verzögerungen und Wartezeiten verwenden 0, und Handler können über config() oder Auftragseigenschaften einen höheren positiven Wert festlegen. Nur cost_units einer Schrittdefinition kann den Wert 0 festlegen.

Das ist nützlich, wenn ein Workflow denselben Bereich erneut durchlaufen oder For-each-Schritte Arbeit ausführen können, deren Kosten sich nicht allein anhand der Schrittzahl erfassen lassen. Ein Planer, der wiederholt einen kostspieligen Modellaufruf ausführt, kann zwar innerhalb von max_transitions() bleiben, aber dennoch das vorgesehene Kostenlimit überschreiten.

max_started_workflows()

Begrenzt, wie viele Workflows der obersten Ebene eine Ausführung über start_workflows() oder start_agents() starten darf. Das Limit wird geprüft, bevor die untergeordneten Workflows gestartet werden. So schlägt der übergeordnete Workflow fehl, ohne teilweise eine Gruppe anzulegen, die das Limit bereits überschreitet.

Wird ein Limit überschritten, lässt Queuety den Workflow sofort fehlschlagen, statt den Schritt erneut auszuführen. Eine Ausnahme: Wenn Queuety::signal() eine Wartezeit abschließt und der daraus folgende Übergang ein Limit überschreitet, wird die Ausnahme an den Aufrufer von signal() weitergegeben, das Signal wird zurückgerollt und der Workflow wartet weiter.

Schutzmaßnahmen beobachten

Der Workflow-Status stellt Folgendes bereit:

• definition_version
• definition_hash
• idempotency_key
• budget

Die Nutzdaten von budget enthalten konfigurierte Limits und die aktuelle Nutzung, darunter die Größe des aktuellen öffentlichen Status in Bytes.

Beispiel:

$state = Queuety::workflow_status( $workflow_id );

$state->definition_version; // 'research.v2'
$state->definition_hash;    // '4c7a...'
$state->idempotency_key;    // 'brief:42:research'
$state->budget;             // [ 'max_transitions' => 20, ... ]