Here's the PR body:
## Summary
Checkout called the FX provider on every cart render. During Friday's sale that went over the provider's 1,000 requests/minute limit, and checkout started returning 429 errors. `get_rate` now keeps each rate in memory for 5 minutes.
```diff
get_rate(base, quote)
+ if base:quote was fetched less than 300s ago
+ return the saved rate
GET api.example-fx.com/latest
raise on HTTP error
+ save rate for base:quote with time.monotonic()
return rate
Evidence
-
Before:
pytestshows 14 passed. Everyget_ratecall makes its own HTTP request.
After:pytestshows 15 passed. Addedtest_get_rate_uses_cache_within_ttl:get_rate("USD", "EUR") get_rate("USD", "EUR") assert provider was called once
Merge Danger
Door: two-way
The cache only lives in memory, with nothing persisted and no schema change. To roll back, revert the commit.
Blast Radius: checkout
- Stale rates: prices can use a rate up to 5 minutes old. Confirm that's acceptable for checkout pricing.
- Per-process cache: each worker keeps its own cache. Provider calls per 5 minutes are roughly workers × currency pairs, so the limit could still be reached with many workers.
- No size limit or eviction: this is fine for a fixed set of currency pairs.
- No locking: two requests that miss the cache at the same moment can both call the provider. The only cost is an extra request.
- Test isolation:
_cacheis module-level, so it carries over between tests unless a fixture clears it.
- **No `GLOSSARY.md`:** the repo doesn't have one, so I used the wording from your context and the code.
- **Check this before merging:** `test_get_rate_returns_quote` already caches `USD:EUR`. If nothing clears `_cache` between tests, the new test should see 0 provider calls and fail. Since it passes, the `mock_get` fixture probably resets the cache, but I couldn't see the fixture to confirm. If it doesn't, the test result depends on the order tests run in, and I'd add an autouse fixture that calls `_cache.clear()`.
Real run recorded with claude-code / claude-opus-5-5. Output is shown verbatim, unmodified. The only change: the trial machine's temp-folder path was replaced with a generic placeholder.
Was es macht
Schreibt eine Pull-Request-Beschreibung, die sich schnell reviewen lässt, in drei Teilen.
So funktioniert es
- Summary: die kleinste Visualisierung, die den Punkt trifft: Pseudocode, Aufrufbaum, Komponentenbaum, Dateibaum, Mermaid-Diagramm oder Diff-Skizze, neben dem kurzen Text platziert, den sie stützt.
- Evidence: ein konkretes Vorher und Nachher. Bei visuellen Änderungen sind Screenshots am besten, sonst der genaue Test, der jetzt von fehlschlagend auf bestanden wechselt.
- Merge Danger: ob die Änderung eine Einbahn- oder Zweiwegetür ist (lässt sie sich zurückrollen?) und wie groß der Wirkungsradius ist, etwa Layout-Verschiebung oder Brüche bei Nutzern.
- Verzichtet auf Vorreden, hält den Text kurz und nutzt die Begriffe aus
GLOSSARY.md, falls vorhanden.
Geeignet für
Pull Requests, bei denen Reviewer sehen müssen, was sich ändert und wie riskant es ist.
Gut zu wissen
In unserem Test wies es auch auf ein Risiko hin, das sich aus dem Diff allein nicht prüfen ließ (Testisolation), statt es zu verschweigen.
Reine Anweisungsdateien: keine Skripte, kein Netzwerkzugriff. Die Auswahl an Visualisierungen im Abschnitt Summary ist vom show-me-Skill von Dex Horthy (HumanLayer, MIT-Lizenz) angepasst; das Paket enthält diese Lizenz als LICENSE-show-me und einen Hinweis in CREDITS.md. Es schreibt nur Text und führt weder git aus noch öffnet es den Pull Request. Das Paket enthält außerdem die MIT-Lizenz (LICENSE) des Original-Repositorys und agents/openai.yaml (Anzeigename für Codex).