Workflow DevKit 5 fail-fast refusals: which Sume errors to retry

Workflow DevKit v5.0.1, dated October 1, 2026, changed dynamic start() refusals to fail fast instead of retrying. Sume has the same split. A 400 invalid_request or a 402 insufficient_credits will fail again if you resend it. A 429 or 503 can succeed later, and you should resend it with the same Idempotency-Key.

What changed in the release

The Releasebot entry says dynamic start() refusals "are now fatal, so a start() inside a step fails fast instead of retrying". A refusal is an answer, not a transient fault, so retrying wastes time and, for a paid step, can waste money.

A retry rule for Sume

Classify by status and code, not by whether the status is a 4xx or 5xx.

A classifier

This function returns whether a step should be retried. It reads the error code from the JSON envelope.

NO_RETRY = {"invalid_request", "bad_request", "unauthorized",
            "insufficient_credits", "not_found"}
RETRY = {"rate_limited", "provider_capacity_exceeded"}

def should_retry(status: int, body: dict) -> bool:
    code = (body.get("error") or {}).get("code", "")
    if code in NO_RETRY:
        return False
    if code in RETRY:
        return True
    return status in (429, 503) and code != "queue_full"

Keep the same idempotency key

Send an Idempotency-Key on submits. A replay with the same key returns the original job, so a retry after a timeout does not create a second paid job. Do not retry unsafe submit requests without one.

If your workflow engine retries a whole step, the key has to be created once, outside the step body, and passed in. Otherwise each attempt makes a new key and a new job.