Request Deadline
A request deadline is the time after which a client stops waiting. Each downstream call should receive only the time that remains.
absolute deadline -> remaining timeout -> propagate -> cancel -> stop spawned work13:00:00.800620 ms leftabsolute deadline -> remaining timeout -> propagate -> cancel -> stop spawned workSREAnother example
Checkout starts with 800 ms. The API gives inventory the remaining 620 ms. The call is cancelled at zero. The server then stops its spawned work.
Main parts
- 01Start time
- 02Absolute deadline
- 03Elapsed time
- 04Remaining time
- 05Cancellation signal
- 06Cleanup path
Use it when
Set a deadline on remote calls. Choose it from user needs and measured latency. Pass the remaining time through the call chain.
Do not use it when
Do not pick a tiny number without data. Stopping the wait is not enough. Servers must also notice cancellation and stop work.
Name used in code
absolute deadline -> remaining timeout -> propagate -> cancel -> stop spawned work Before you ship
Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback.
Outcome: Design or review Request Deadline for this system while keeping data correct, secure, and easy to operate. User context: Checkout starts with 800 ms. The API gives inventory the remaining 620 ms. The call is cancelled at zero. The server then stops its spawned work. Technical concept or control: Request Deadline. Why it fits: Set a deadline on remote calls. Choose it from user needs and measured latency. Pass the remaining time through the call chain. Do not use it when: Do not pick a tiny number without data. Stopping the wait is not enough. Servers must also notice cancellation and stop work. Engineering requirements: Define inputs, outputs, contracts, and rules that must always hold. Set authorization and input checks. Define failures, timeouts, retries, one-time effects, data moves, and compatibility limits. Operations: Add useful signals and logs that hide sensitive data. Set capacity limits and write an operator guide. Test recovery and rollback. Acceptance criteria: Contract and failure-path tests pass. Data and authorization rules still hold during retries and partial failures. Check performance limits, monitoring, recovery, and rollback. Evidence and limits (evidence boundary): No single official standard controls the whole term. Its meaning may change across teams, platforms, or frameworks. Unknowns to confirm: Where the code runs, data stores, traffic shape, consistency needs, and the security boundary. Also confirm the compatibility period, service goals, and rollback limits.
Check this request
Review the current use of Request Deadline. Definition: A request deadline is the time after which a client stops waiting. Each downstream call should receive only the time that remains. Release checks: Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback. Before changing code, report the evidence you found, gaps, severity, and the smallest safe fix.