Connect, read and total limits, and a cancel, on a simulated clock
Time is a number in milliseconds, so there is no real waiting and the output never changes.
A model call can take seconds or hang for minutes. Set a connect timeout, a read timeout and a total deadline on every call, pass the remaining time down, and cancel calls whose answer nobody needs any more.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 6 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Write remaining_ms(deadline_ms, now_ms) that returns the time left, never below zero, and step_timeout(remaining, cap) that returns the smaller of the two.
A request has a 20,000 ms deadline starting at time 0. Retrieval ends at 3,000 ms. Print the timeout in ms you would give the model call if you cap any single call at 15,000 ms.
Explain it without notes
What are connect, read and total timeouts and why do you need all three?
How do you choose a timeout value for a model call?
Why should a user cancelling a request also cancel the model call?
Expected output
healthy -> ok at 900 ms with 3 chunk(s)
slow connect -> connect timeout at 1000 ms
stalled reply -> read timeout at 2600 ms after 2 chunk(s)
slow trickle -> deadline exceeded at 8000 ms after 5 chunk(s)
no limits at all -> ok at 4000 ms with 3 chunk(s)
user cancels -> cancelled at 600 ms after 1 chunk(s)