Workflow SDK 5: Lange AI-Jobs brauchen einen klaren Abbruchvertrag

Tech

Lange AI-Workflows scheitern selten nur daran, dass sie lange laufen. Kritisch wird es, wenn niemand erklären kann, was nach einem Abbruch noch weiterläuft. Ein Modellaufruf läuft trotz Nutzerabbruch weiter, ein Upload endet nach einem Timeout, oder ein Quota-Wächter stoppt zu spät.

Vercel meldete am 16. Juni 2026, dass Workflow SDK 5 beta AbortController und AbortSignal über Workflow- und Step-Grenzen hinweg unterstützt. Zusammen mit längeren Sandbox-Laufzeiten zeigt das: Agenten und durable Jobs dürfen länger laufen, müssen aber präziser stoppbar sein.

Diagramm eines Workflow-SDK-Laufs, der AbortController-Signale an Schritte weitergibt und bei Timeout, Nutzerabbruch oder Quota-Limit stoppt
Der operative Kern ist ein expliziter Vertrag: welcher Schritt welches Signal erhält, wie er beendet wird und welche Aufräumaktion sichtbar bleibt.

Was sich geändert hat

Ein Workflow kann einen AbortController erzeugen, das Signal an Steps weiterreichen und bei Timeout, Race, Hook oder Quota-Regel abbrechen. Laut Dokumentation bleibt das Signal über Suspensions, deterministische Replays und getrennte Function Invocations hinweg haltbar.

Cancellation bleibt kooperativ. Ein Step muss das Signal an fetch oder eine unterstützte API weitergeben, signal.throwIfAborted() aufrufen oder signal.aborted prüfen. Ohne diese Beteiligung läuft der Step weiter.

Warum das zählt

OCR, Reports, Browser-Automation, Multi-Model-Agenten und Tests profitieren von längeren Laufzeiten. Ohne Abbruchvertrag entstehen aber verschwendete Tokens, doppelte Webhooks, gesperrte Ressourcen und unklare Jobzustände.

Community-Fragen zu Produktionsreife, cancel/kill/cleanup zeigen, dass Teams weniger nach Syntax fragen als nach einem Betriebsmodell.

Praktische Auswirkungen

Timeouts werden zu Produktregeln, nicht nur zu Plattformlimits. Parallel gestartete Provider lassen sich nach dem ersten Erfolg sauber stoppen. Abort-Fehler werden nicht wie normale Fehler erneut versucht, was Incident-Analysen klarer macht.

Checkliste

Definiere Nutzerabbruch, Timeout, Admin-Stopp, Quota-Limit und Parent-Request-Ende als separate Gründe.

Jeder teure Step sollte ein Signal annehmen und vor teurer Arbeit prüfen.

Unterscheide run.cancel() vom AbortSignal: ganzer Lauf gegen spezifische In-flight-Operation.

Speichere cancelled_by_user, timed_out oder quota_exceeded als eigene Statuswerte.

Teste Partial Uploads, externe Jobs, E-Mails und Webhooks separat.

Risiken

Workflow SDK 5 ist beta/pre-release. Starte mit internen Workflows, pinne Versionen und halte Rollback bereit.

AbortSignal macht keine rückwirkende Transaktion. Bibliotheken können das Signal ignorieren, und externe Side Effects können trotzdem fertig werden.

Nächster Schritt

Zeichne für bestehende lange Jobs zuerst die Abbruchgrenzen: kostenintensive Steps, externe Mutationen und nicht wiederholbare Aktionen. Danach erst lohnt sich die konkrete SDK-Integration.

30-Minuten-Check vor der Einführung

✓ Abbruchgründe sind in Produktsprache benannt

✓ Teure Schritte erhalten oder prüfen ein Signal

✓ Abort und Retry widersprechen sich nicht

✓ Externe Side Effects haben Idempotency Keys

✓ Monitoring trennt cancelled von failed

const controller = new AbortController();
const result = await Promise.race([
  expensiveStep(controller.signal),
  sleep("30s").then(() => null),
]);
if (result === null) controller.abort();

Quellen und weiterführende Links

다른 글