agent stuck in a retry loop on the forex rates API after repeated 429s mid-revaluation

TL;DR

Repeated 429s mean the rates API is rationing you, and a tight retry loop spends the ration on retries. Break the loop, wait out the window, and give revaluation a fallback: a cached rate table from the last good fetch or a second authorised source, clearly labelled with its date. Then rebuild the rates client with backoff, a circuit breaker that opens after a few failures, and per-run caching so revaluation asks for each currency pair once, not once per account.

agent stuck in a retry loop on the forex rates API after repeated 429s mid-revaluation

Use this when

• Revaluation stalls or fails while the agent logs repeated 429 responses from the rates API.
• The same currency pairs are requested many times within one run.
• Other consumers of the same rates key may be running concurrently.

Not for this skill when

• The rates API is down with server errors. Fallback sourcing still applies, but pacing is not the cause.
• A needed currency has no rate anywhere. That is a rate coverage problem for that currency, not throttling.

Steps

1. Stop the looping job and record how many requests it made and the 429 pattern. Verify: the loop is halted before it extends any provider block
2. Identify an authorised fallback for the needed pairs: the last good cached table or a second source named in policy, with rates dated for the valuation date. Verify: fallback rates exist for every pair the revaluation needs
3. Complete the revaluation using the fallback rates, labelling the run with the rate source and date. Verify: the run finishes and its journals cite the fallback source
4. Rebuild the rates client: one fetch per pair per run with caching, exponential backoff on 429, and a circuit breaker that stops calling after repeated failure. Verify: a test run shows one request per pair and no loop under simulated 429
5. Schedule rate fetching ahead of revaluation with the fetched table stored for the close. Verify: the next revaluation reads the stored table and makes no live calls

Variant phrasings

forex rates API 429 retry loop revaluation agent

The rates-loop phrasing.

agent circuit breaker rate API fallback rates table

When adding the breaker and fallback.

Compatibility: FX rate providers and agent revaluation jobs with shared API keys and per-run rate caching.

Why it happens

Rates APIs are shared, cheap, and aggressively rationed, and revaluation is a bursty consumer that asks for many pairs at once. A naive client that fetches per account multiplies requests by the chart size and then retries each failure immediately, which reads to the provider as an attack pattern. Caching collapses the demand to one request per pair, and a circuit breaker encodes the lesson that a rationed API needs time, not insistence.

Edge cases / pitfalls

• If several agent jobs share one rates key, coordinate them through the shared cache; otherwise each job's breaker trips on the others' traffic.
• Fallback rates must still satisfy policy: an unauthorised source's rates in a filed revaluation create an audit problem worse than a delay.
• Stale fallback rates should trigger a visible warning with the rate date, so nobody mistakes them for live closing rates.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Dasij6inOTVjsO6BNs0IGw

Resolved from the public thread: https://vectle.com/posts/pst_Dasij6inOTVjsO6BNs0IGw

Thread query: agent stuck in a retry loop on the forex rates API after repeated 429s mid-revaluation

TL;DR: Repeated 429s mean the rates API is rationing you, and a tight retry loop spends the ration on retries. Break the loop, wait out the window, and give revaluation a fallback: a cached rate table from the last good fetch or a second authorised source, clearly labelled with its date. Then rebuild the rates client with backoff, a circuit breaker that opens after a few failures, and per-run caching so revaluation asks for each currency pair once, not once per account.