Errors, retry logic, and recovery
Words made simple
A few useful meanings before you read the explanation.
- LLM
- A model trained to work with language. It can write or summarize text, but its answer still needs checking against reliable information.
- Checkpoint
- A saved snapshot of workflow progress that can help it continue later.
- Persistence
- Saving information so it remains available after a request ends or a process restarts.
More words from this lesson
- Idempotency
- Making a repeated request have the same intended business effect as one request. It helps avoid duplicate submissions or payments.
- Authorization
- Checking what that identity is allowed to read or do. Being logged in does not grant access to every record.
- Backoff
- Waiting before retrying a failed request. Increasing the wait can help avoid repeatedly overwhelming a busy service.
- Dependency
- A library or package that your application relies on. Compatible versions help the application run as expected.
Overview
- Error handling distinguishes recoverable infrastructure failures, invalid user input, unsupported model decisions, and business failures.
- Retry repeats an operation after an appropriate transient failure.
- Recovery uses persisted progress and reconciliation to continue safely.
Why this matters
Provider timeouts and worker restarts are normal production events.
An everyday example
Call a busy department again later; do not keep resubmitting a rejected form with unchanged fields.
A technical example
Retry a read on transient 503; ask for a missing document; do not retry permission denial; reconcile a timed-out submission by idempotency key.
How it works
- Classify error
- Select bounded policy
- Apply backoff with jitter where appropriate
- Preserve original error
- Update status
- Resume or escalate.
Architecture and flow
Node failure → classification → retry / user correction / reconcile / fail.
The insurance assistant example
A claim-create timeout may mean the claim was created but the response was lost; verify before retrying.
When to use it
Every external dependency and consequential action.
When to avoid it
Do not apply automatic retries to non-idempotent writes without reconciliation or repeatedly ask the LLM to fix an authorization failure.
Interview answer
“I retry transient failures with bounds, keep user and permission failures distinct, and make side effects idempotent because recovered nodes may execute again.”
Benefits, trade-offs, and production considerations
- Per-node retry limits multiply with provider retries and whole-run retries.
- Set one total deadline and cost budget.
- Record unknown commit outcomes explicitly; a checkpoint alone cannot prove whether an external service applied a write.
Can you explain it without the notes?
Errors, retry logic, and recovery
Use your own words. Explain an example and one limitation before checking the explanation.
Check your explanation
Error handling distinguishes recoverable infrastructure failures, invalid user input, unsupported model decisions, and business failures. Retry repeats an operation after an appropriate transient failure. Recovery uses persisted progress and reconciliation to…
Turn this concept into a clear answer.
Practice this conceptAdapted from 13_AI.MD · “Errors, retry logic, and recovery”. Examples are study fragments; framework behavior can depend on your version.