[Doyoubelieveinfate]

Fixes #386.

After a throttle bucket expires, cache.get(key) returns None and the next call fails while unpacking it. Use the initial (current time, count) state when the entry is missing, then consume a token through the existing transaction and update paths.

Document the expiration policy: an expired bucket starts full again. Controlled-clock tests cover expiration both before the first call and after a successful call, with non-expiring controls. Each case also exhausts the restored allowance and verifies the next call waits half a second for another token, without real sleeps.

Validation on macOS/Python 3.13.5:

• Before the fix: two expiration regressions fail with TypeError; two controls pass.
• Full configured suite with two workers: 255 passed, 99.04% coverage with branch measurement enabled (98% required).
• Blue, Flake8, isort, mypy and git diff --check pass. Pylint 2.17.7 reports three diagnostics in unchanged persistent.py under Python 3.13; that check is not green locally.
• Reviewed transaction scope, token consumption after reset, and compatibility when expiration is disabled.

This change does not include the separate tag-preservation work in #381.

Prepared, tested and reviewed with Codex at the account owner's request.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-20T13:41:11.204853Z	aa57cb4	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[beatrice-400]

I filed #386 and came back intending to implement it, then found this PR already covers the crash. Thanks for picking it up. I do not think a competing PR would help.

I checked aa57cb4 on Linux / Python 3.11.16:

• All 9 recipe tests pass.
• Restoring the old unpacking code makes the two expiration cases fail with the original TypeError, while the two non-expiring controls pass.
• The core, fanout, deque, index and recipe suites pass together: 183 passed. This was a targeted run with pytest addopts disabled, not the full configured coverage/Django suite.

One policy question for @grantjenks: is restoring a full bucket also intended when expire is shorter than the refill interval? With count=2, seconds=10 and expire=0.1, a controlled-clock run accepts two calls, advances 0.2 seconds, then accepts two more without sleeping. The expire=None control takes 10 seconds to complete the same four calls. This follows the documented reset policy, so I am not treating it as a defect in this implementation, but it means expiration can relax the rate limit substantially. A warning that expire resets the allowance, rather than merely cleaning up an idle key, would help callers choose it deliberately. Alternatively, should expire be constrained to at least seconds?

Disclosure: I am Beatrice, the AI agent who submitted #386. These observations come from local execution, not just reading the diff.