Loadingone moment…
Sign in to run and submit your work
Reading is open to everyone. Running code and saving drafts need an account so your work is yours and comes back on your next visit.
or
CODE WORKSPACE
When the warehouse rejects a load, the pipeline retries. Retrying immediately makes a struggling database worse, so the wait doubles each time — but doubling without a limit means the eighth attempt waits longer than the whole job is allowed to run, and the worker sits idle holding a slot.
Write backoff_schedule(attempts, base, cap, budget). Return the wait before each retry, in order.
Function to write
backoff_schedule(attempts: int, base: float, cap: float, budget: float) -> list[float]The wait in seconds before each retry, in order, respecting the per-wait cap and the total budget.
How to approach it
Cap each wait as you compute it, and test the running total before you commit to it.
Sample cases
+ 2 held back until you submit
a normal retry policy
Six attempts doubling from one second, with the cap biting at the sixth.
Input
Argument 1
6Argument 2
1Argument 3
30Argument 4
600Returns
[
1,
2,
4,
8,
16,
30
]no retries allowed
Zero attempts is an empty schedule rather than one immediate retry.
Input
Argument 1
0Argument 2
1Argument 3
30Argument 4
600Returns
[] (empty list)
a tight time budget
The budget runs out partway through, so the schedule stops rather than overrunning it.
Input
Argument 1
10Argument 2
2Argument 3
60Argument 4
20Returns
[
2,
4,
8
]Constraints
base seconds and each one after it doubles.cap. Once the doubling passes the cap, every later wait is the cap.budget. Stop and return what fits rather than including a wait that breaks it.attempts waits. Zero or fewer attempts is an empty schedule.base of zero or less has no schedule — waiting no time is not a backoff.cap below the base flattens the schedule to the cap rather than producing anything negative.Worked example
With a base of 1.0, a cap of 30.0 and six attempts the waits are 1, 2, 4, 8, 16 and then 30 — not 32, because the cap catches the sixth. Together they are 61 seconds, comfortably inside a budget of 600.0. The tight-budget case is where the rules interact. Starting from 2.0 with a budget of 20.0, the waits 2, 4, 8 come to 14; the next would be 16, taking the total to 30. The schedule stops at three retries. Adding the fourth and letting the caller notice afterwards is the version that overruns the job's deadline, because by the time anyone checks, the wait has already happened.
What this tests
Two limits of different kinds — one per item, one cumulative — applied in the right order. Checking the budget before committing to the wait is the difference between a bounded job and one that is bounded on average.
backoff_schedule(attempts: int, base: float, cap: float, budget: float) -> list[float]Submit for review to find out what your query gets right, what it gets wrong, and how it compares with the best working query for this exercise.
This scenario runs a full workspace — editor, canvas and results side by side. It needs a laptop or desktop to be usable. Open this page on a bigger screen to start building.