Split out of #35, which deliberately stopped failing the nightly fetch on this.
What
data/universes/stoxx600.json holds 463 tickers. 118 of them have never served a single row and have no file in data/market/ohlcv/. They are Refinitiv/Reuters-style codes, not Yahoo symbols:
| in stoxx600.json |
Yahoo wants |
AIRP.PA |
AI.PA |
BNPP.PA |
BNP.PA |
CAGR.PA |
ACA.PA |
ATCOa.ST |
ATCO-A.ST |
AMBU B.CO |
AMBU-B.CO |
Others in the set: ADH.OL, AKERBP.OL, ALLFG.MC, AMS.VI, ARGX.AS, ARND.DE, ASMI.AS, ASSA B.ST, BALD B.ST, BALN.SW, BEB.SW, BRNW.MI, BT.A.L, CAPP.PA, CARR.PA, CASP.ST, CCH.SW, CTS.DE, DANO.PA …
Why it matters
roster.yaml assigns stoxx-600 to four agents. Their universe resolvers hand those names to agents as tradable; the price store can never cover them, so an order on one is rejected at the broker with NO_PRICE_DATA and the agent has burned a session slot on a trade that could never fill.
Why it is not a red build
Until #35 this condition failed the whole nightly run — which is what froze the price store from 2026-08-06 to 08-10. Failing the fetch cannot fix a bad universe file, and holding the store hostage to it broke the desk. The script now prints WARN: N symbol(s) have never served a row to stderr and exits 0.
That WARN has no automated consumer by design, so this issue is the consumer. Per the W2.10 rule that a red X is not a consumer: a stderr line under a green tick is weaker still, and the right home for a static data defect is a ticket, not a recurring failure.
Fix
Correct the symbol formats in whatever produces stoxx600.json (scripts/refresh_universes.py → the STOXX 600 resolver) so the refresh emits Yahoo symbols, then re-run the refresh and a full fetch_ohlcv.py --backfill for the corrected names.
Verify with python scripts/fetch_ohlcv.py --dry-run plus a store-coverage count; the WARN line should drop to roughly zero.
Done when
Split out of #35, which deliberately stopped failing the nightly fetch on this.
What
data/universes/stoxx600.jsonholds 463 tickers. 118 of them have never served a single row and have no file indata/market/ohlcv/. They are Refinitiv/Reuters-style codes, not Yahoo symbols:AIRP.PAAI.PABNPP.PABNP.PACAGR.PAACA.PAATCOa.STATCO-A.STAMBU B.COAMBU-B.COOthers in the set:
ADH.OL,AKERBP.OL,ALLFG.MC,AMS.VI,ARGX.AS,ARND.DE,ASMI.AS,ASSA B.ST,BALD B.ST,BALN.SW,BEB.SW,BRNW.MI,BT.A.L,CAPP.PA,CARR.PA,CASP.ST,CCH.SW,CTS.DE,DANO.PA…Why it matters
roster.yamlassignsstoxx-600to four agents. Their universe resolvers hand those names to agents as tradable; the price store can never cover them, so an order on one is rejected at the broker withNO_PRICE_DATAand the agent has burned a session slot on a trade that could never fill.Why it is not a red build
Until #35 this condition failed the whole nightly run — which is what froze the price store from 2026-08-06 to 08-10. Failing the fetch cannot fix a bad universe file, and holding the store hostage to it broke the desk. The script now prints
WARN: N symbol(s) have never served a rowto stderr and exits 0.That WARN has no automated consumer by design, so this issue is the consumer. Per the W2.10 rule that a red X is not a consumer: a stderr line under a green tick is weaker still, and the right home for a static data defect is a ticket, not a recurring failure.
Fix
Correct the symbol formats in whatever produces
stoxx600.json(scripts/refresh_universes.py→ the STOXX 600 resolver) so the refresh emits Yahoo symbols, then re-run the refresh and a fullfetch_ohlcv.py --backfillfor the corrected names.Verify with
python scripts/fetch_ohlcv.py --dry-runplus a store-coverage count; the WARN line should drop to roughly zero.Done when
data/universes/stoxx600.jsonis refreshed and committed.data/market/ohlcv/.fetch-ohlcvrun prints nohave never served a rowWARN (or a residual count that is understood and recorded here).