Sikkerhedsforanstaltninger for workflows

Agentlignende workflows er fleksible, men gør det også lettere at oprette dublerede kørsler eller lade en planner producere mere arbejde end tilsigtet. Queuety giver lette sikkerhedsforanstaltninger på workflowniveau, så du kan bevare fleksibiliteten uden at miste kontrollen.

Se Ressourcestyring for den bredere ressourcemodel omkring worker-admission og metadata om omkostninger pr. job.

Versionering af en workflowdefinition

Brug version() til at knytte en versionsetiket på programniveau til en workflowdefinition:

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

Versionen gemmes sammen med workflowtilstanden, vises via workflow_status(), udskrives af wp queuety workflow status og medtages i workfloweksporter.

Queuety gemmer også en deterministisk definition_hash for hver workflowkørsel. Hashen er afledt af den serialiserede workflowdefinition og er nyttig, når du efter en udrulning skal identificere præcis, hvilken workflowstruktur en igangværende kørsel udfører.

Gør dispatch idempotent

Brug idempotency_key(), når kaldere kan gentage den samme anmodning:

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

Hvis et workflow sendes igen med en nøgle, der allerede er brugt, returnerer Queuety det oprindelige workflow-ID i stedet for at oprette en dubletkørsel. Nøgler er globale på tværs af workflownavne, så medtag workflownavnet i nøglen, hvis forskellige workflows kan dele den.

Dette er især nyttigt til:

• API-endepunkter, hvor klienter eller gateways kan forsøge igen
• webhookforbrugere, der kan modtage dublerede leveringer
• plannertrin, der kun bør oprette én orkestreringskørsel pr. ekstern enhed

Idempotensnøgler gemmes i tabellen queuety_workflow_dispatch_keys.

Angiv workflowbudgetter

Brug workflowbudgetter til at få kørsler til at fejle, hvis de overskrider den ramme, du har planlagt:

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()

Begrænser, hvor mange workflowtrin der kan fuldføres, før kørslen fejler. Det er nyttigt til at beskytte workflows, der forgrener sig dynamisk eller kan vende tilbage til samme område via _next_step.

max_for_each_items()

Begrænser, hvor mange elementer, der findes under kørslen, et enkelt trin med for_each() må udvide til. Det er nyttigt til planner/executor-systemer, hvor en agent kan finde langt mere forgreningsarbejde end tilsigtet.

max_state_bytes()

Begrænser den kodede størrelse af den offentlige workflowtilstand. Det hjælper med at forhindre, at langvarige workflows vokser til store klumper, der er langsomme at inspicere, eksportere eller prøve igen.

max_cost_units()

Begrænser det samlede antal forbrugte omkostningsenheder for fuldførte trin. Omkostningsenheder kommer fra trin- eller jobmetadataene, som Queuety slår op, når arbejdet sættes i kø. Almindeligt brugerarbejde har som standard værdien 1, orkestreringspladsholdere som forsinkelser og ventetider bruger 0, og behandlere kan angive en højere positiv værdi via config() eller jobegenskaber. Kun en trindefinitions cost_units kan angive værdien 0.

Det er nyttigt, når et workflow kan vende tilbage til samme område eller for hver gennemgang af arbejde, der er dyrt på måder, som ikke alene afspejles i antallet af trin. En planner, der bliver ved med at køre et dyrt modelkald igen, kan holde sig inden for max_transitions() og stadig overskride den omkostningsramme, du havde tiltænkt.

max_started_workflows()

Begrænser, hvor mange workflows på øverste niveau en kørsel må starte via start_workflows() eller start_agents(). Grænsen kontrolleres, før underordnede workflows sendes afsted, så det overordnede workflow fejler uden delvist at oprette en gruppe, der allerede overskrider budgettet.

Når et budget overskrides, fejler Queuety workflowet med det samme i stedet for at prøve trinnet igen. Én undtagelse: Når Queuety::signal() afslutter en ventetid, og den resulterende overgang overskrider et budget, kastes undtagelsen til kaldet af signal(), signalindsættelsen rulles tilbage, og workflowet fortsætter med at vente.

Overvågning af værn

Workflowstatus viser:

• definition_version
• definition_hash
• idempotency_key
• budget

Nyttelasten budget indeholder konfigurerede grænser samt aktuelt forbrug, herunder størrelsen i byte af den aktuelle offentlige tilstand.

Eksempel:

$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, ... ]