Start with the ladder's arithmetic, because it decides whether the deadline check is live code. `full_jitter_delay` computes `ceiling = min(cap_seconds, base_seconds * (2 ** attempt))` and returns a uniform draw between zero and that ceiling, with `base_seconds=5` and `cap_seconds=900` [10]. `next_state` returns `dead_letter` once `attempt` reaches `max_attempts`, default 8 [11]. The largest ceiling it can ever compute is at attempt 7, which is 5 * 128 = 640 seconds, so the 900-second cap is unreachable configuration under those defaults [2].
The worked example sets a deadline 30 minutes out, an attempt counter of 3, and an expected attempt time of 20 seconds [12]. At attempt 3 the ceiling is 40 seconds [1]. Sum the ceilings for attempts 0 through 7 and the worst realization of the whole ladder waits 1275 seconds; add eight 20-second attempts and the run lands 365 seconds inside the 1800-second window, so the only reachable route to `dead_letter` here is attempt exhaustion [3][4]. With full jitter the mean draw is half the ceiling, putting a typical run at about 10.6 minutes [5]. For the deadline branch to fire you need a window shorter than roughly 21 minutes, or a ladder widened until the waits can outrun it. That is a tuning job, and the defaults published alongside the argument do not do it.
`expected_attempt_time` arrives as a caller parameter [11]. The guarantee is therefore exactly as conservative as whatever the caller passes, and the estimate has to cover DNS, connection setup, the request, the response classification, and the persistence of the resulting state transition, because the source's rule is that a worker acknowledges only after that persistence [7]. Feed it a median and you have built a coin flip with a timestamp.
One more detail about the artifact. The source presents the model as deliberately a pure function so that boundary tests are less fragile than tests coupled to a queue library [13]. It is not pure: the delay comes from `random.uniform` [10], so two calls with identical inputs can return different states, and they will diverge most often at exactly the boundary the tests exist to pin. Pass the delay in, or seed the generator in the test. The one place the code is advertised as sturdy is the one place the RNG votes.
The classification policy has the same shape problem. Timeouts are retryable, rate limits are retryable with the server's delay where policy permits, most other client errors need correction, and authentication failures get quarantined and escalated [8]. None of that is expressible in a function whose return type is `retry` or `dead_letter` [11]. Quarantine needs its own persisted state and its own operator surface, or the escalation is a log line nobody reads.
What adoption actually costs: every enqueue site learns to stamp `deadline_at`, since the source's non-negotiable line is that the deadline belongs in the message [14]; the signing path has to exclude the wall clock so a retry stays the same logical message under HMAC over the bytes sent [6]; and the DLQ needs redrive tooling plus a human policy for which expired reminders are still worth sending [1]. In my context, a commercial window that closes, that is the right trade. If the deadline is soft, `deadline_at` is just another field in the envelope.
