Check Which Layer the Timeout Belongs To
Added 2026-11-02
A timeout belongs where it can be handled, not just where it fires first.
Here is a call chain with its current timeouts. Check: 1) whether each layer's timeout is larger than the next layer's, otherwise the caller gives up while the callee keeps working; 2) which timeouts fire without proper handling — retry, degrade, error; 3) one case that looks like a timeout but is actually resource starvation; 4) a sensible layered timeout scheme; 5) the common trap when timeouts and retries are combined. Do not just suggest increasing the timeout.
Site original
Chinese original
How to use
超时不是越短越好，而是要和下一层对齐。
Try tweaking it
- Have it restate requirements and constraints before writing code.
- Ask for the smallest change plus a rollback path, not a full-file rewrite.
What you should get
- A minimal, runnable change with copy-ready code
- Impact list: which files and call sites must follow
Common mistakes
- Asking it to touch ten files at once, then losing track of what broke what.
- Pasting only the error, with no code or version, and getting an unfixable answer.
How to check the output
- The change runs, can be rolled back, and touches nothing unrelated.
- Edge cases (empty, oversized, concurrent) are covered or explained.
Where it works
- Good for: having it restate requirements and constraints, then propose the smallest runnable change.
- Watch out: include versions and a minimal reproduction with the error, or the fix may look plausible but not fit.
Good for
- You see intermittent timeouts in production but cannot tell whether they happen at the caller, the callee or an intermediate proxy.
- You are about to adjust a batch of timeout values and worry you will only move the failure from one layer to another.
Not for
- The service has no timeout control at all and calls can wait forever — add timeouts first, then discuss layers.
- You have already traced the problem to one slow downstream and can optimise it directly; changing timeouts now just hides it.
Example
Input
Gateway 30s, service A calls B with a 5s timeout, B queries the database with a 3s timeout, and the database statement timeout is unset. Symptom: A times out while B logs show the query still running.
What you get
Point out the mismatch first: A waits only 5s, but B can run up to 3s on its own downstream with no database limit, so B keeps working after A gives up. Recommend layers — database statement 2s, below B-to-database 2.5s, below A-to-B 5s, below gateway 30s — and specify what each layer does on timeout: retry, degrade or fail. Also flag that B continuing after A gave up needs handling, via cancellation or idempotent writes.
Common mistakes
- Only increasing timeouts: the layering problem remains and tail latency gets worse as failures are pushed later.
- Setting every layer to the same value: that is not layering, so the caller still gives up while the callee keeps working.
Try tweaking it like this
- Reframe as "retry or fail after a timeout" and the output becomes retry budgets and idempotency checks.
- Add a user-experience view: derive each layer budget by working back from acceptable user wait, instead of picking numbers by feel.