Skip to content

fix(gold): retry a xenon leg once when its idle IB socket was reset - #554

Merged
moremeds merged 1 commit into
mainfrom
fix/gold-factor-xenon-retry
Oct 14, 2026
Merged

moremeds merged 1 commit into
mainfrom
fix/gold-factor-xenon-retry

Conversation

@moremeds

Copy link
Copy Markdown
Owner

What

The nightly gold_factor_compute failed on prod two runs in a row (job_failures.consecutive=2, last 17:46 ET 2026-10-13). Each time the first leg (XAUUSD) got a 503 from xenon and the other six legs got 200.

Cause: xenon's /historical/bars maps ConnectionError to 503 (xenon/api/routes/historical.py). When the idle IB data socket was reset, the first request hits it (ib_async ... [Errno 104] Connection reset by peer right before the 503 in the xenon log at 03:52 UTC 2026-10-14), and the pool reconnects for the next request.

Fix: fetch_ib_legs retries a leg once, 5 s after SourceUnavailable. A second failure is still recorded and the job still raises.

Checks

  • new unit test tests/unit/worker/test_gold_factor_fetch_retry.py (retry succeeds; second failure propagates)
  • ruff, _lint_except, pytest tests/unit/ 3179 passed, gold factor job integration 4 passed
  • prod: a manual run of the job after the failed one got all 7 legs (4070 rows upserted)

xenon answers 503 on the first request after its IB data socket dropped and
reconnects on that request. XAUUSD is fetched first, so the nightly
gold_factor_compute failed on prod twice in a row while the other six legs
passed. fetch_ib_legs now retries a leg once, 5 s after SourceUnavailable.
@moremeds
moremeds merged commit 35c0155 into main Oct 14, 2026
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant