AnyoneLearnAI
Start learning
Chapter DWorkflow automation in codePage 5 of 8

Workflow automation in code

Handle failures and retries

Workflow automation in code is production work only when one frozen failure can be reproduced, one measurable gate can stop a release, and one operator can safely reverse it.

~14 minFailure handling

Before you start

Why this matters

Read this incident aloud: a ticket webhook is delivered three times and the model marks an ambiguous message as urgent. In two minutes, write the earliest deterministic check that should fail, the telemetry signal you would inspect, and the action that must not happen automatically. Compare your answer with this chapter's boundary: verify webhook signatures before parsing; the model proposes actions but cannot send externally.

1Learn the idea

Read

Reproduce failures and debug safely

Reproduce the retry handler posts three Slack alerts because idempotency is recorded after the side effect without editing the prompt first. Load the frozen fixture, set a known release, replace network calls with the failing response, and capture one trace. Confirm that the failure happens twice. If it does not, the reproduction is not controlled enough to support a fix. Debug in transaction order: input acceptance, normalization, retrieval or routing, model/tool decision, output validation, then side effects.

Classify the fault before retrying. Timeouts, 429s, and temporary 5xx responses may be retryable with capped exponential backoff and jitter. Schema violations, authorization mismatches, unsafe tool requests, and failed quality assertions are not transient; retrying repeats risk and cost. Use a maximum attempt count and a deadline. For side effects, retry only behind an idempotency key or transactional outbox.

A fix is complete only when the reproduction becomes a permanent regression case. Add a negative assertion so the old unsafe or incorrect behavior cannot return silently. Preserve the trace ID and policy version in the test output, but redact payloads according to the same production policy. The operational response is to record the proposal transactionally, request human approval, and execute once with an idempotency key.

For failure handling, start with the named reproduction and add controlled timeout, malformed output, duplicate delivery, and forbidden-action variants where relevant. Demonstrate that retries cannot multiply side effects.

Read

Focused implementation artifact

def execute_with_policy(operation, *, attempts=3):
    for attempt in range(attempts):
        try:
            return operation()
        except (TimeoutError, ConnectionError):
            if attempt == attempts - 1:
                raise
        except (PermissionError, ValueError):
            raise  # deterministic or unsafe: never retry

def test_known_failure_is_contained():
    case = {"event_id":"evt_884","signature":"test-valid","occurred_at":"2026-07-18T05:10:00Z","ticket_id":"T-91","text":"Maybe locked out; payroll closes today","dry_run":true}
    decision = workflow.handle(event, actions=RecordingActions(), clock=frozen_clock)
    assert actions.sent == [] and ledger.count("evt_884") == 1

Read

Diagnose before retrying

Run the named reproduction—the retry handler posts three Slack alerts because idempotency is recorded after the side effect—with a frozen clock and recording adapters. Capture the ordered calls and one trace. Re-run it to prove determinism, then locate the first stage whose actual output differs from its contract. Change only that stage. Prompt tuning is not a substitute for an authorization, idempotency, schema, or accounting fix.

Inject a timeout before any side effect and another after the dependency reports success. The first may be retried under a deadline; the second requires reconciliation because blind retry could duplicate work. Prove attempt count, backoff cap, and final error classification. Deterministic policy failures must make one attempt. Side effects require an idempotency key or transactional outbox.

Turn the reproduction into a permanent test and assert the old behavior is absent. Recompute correct actions per unique event under retries so hidden attempts do not improve the denominator. Emit workflow_action_total with error_type from a bounded enum. If containment fails, record the proposal transactionally, request human approval, and execute once with an idempotency key.

Checking tutor…

Continue learning · glossary & guides