[research·parked] A second market-data provider the engine can fail over to on its own

[atomchung]

Status

Research — parked by owner ruling, 2026-07-30. Not this cycle. Split out of #629 so that issue can proceed on the agent-side recovery without this question blocking it.

未来我们可以去探讨有没有第二个数据源来替代 Yahoo Finance，但这一期不用讨论。

Milestone

None — deferred. Revisit when Yahoo's failure rate becomes the binding constraint on review availability, or when someone measures that it already is.

The question

market_data.py has exactly one retrieval source, Yahoo via yfinance. When it is unavailable the engine degrades and #629 has the agent recover the prices by hand. Should the engine instead carry a second provider it can fail over to on its own?

Why it is worth revisiting later, not now

The case for a second provider is stronger than it looks, which is why this is parked rather than rejected:

• Rate limiting is the common failure, not outage. That is precisely the case where the [implementation·M1] Yahoo unavailable on a consider call means recover the prices, not answer on cost #629 agent-side recovery is also slow and awkward — the user waits either way. A second provider is the only option that removes the wait.
• Some sources need no API key (Stooq publishes CSV endpoints), which removes the secret-management objection that usually kills this.
• The [implementation·M1] Yahoo unavailable on a consider call means recover the prices, not answer on cost #629 path always remains as the last resort, so B and A compose rather than compete: engine retries its configured sources, agent recovers only when all of them fail.

The case against, and the reason it is not this cycle:

• A second provider is a second normalization path — currency, split observations, adjusted-vs-raw closes. Divergence between two paths over exactly these facts has produced tenfold errors three separate times in this repository (fix(revisit): exit detection ignores split adjustment, misclassifies a partial trim as a full exit and permanently closes the thesis #550, [bug·data·M1-blocker] Split-blind current book can erase a held position from TradeEvaluation #558, [bug·data·M1-blocker] Split-adjusted shares can be valued against prices on a different split basis #583), and [bug·data·M1-blocker] Split-adjusted shares can be valued against prices on a different split basis #583 exists entirely because a price and a share count sat on two different split bases.
• [architecture·implementation] One market-data resolver — minimum Yahoo calls, one fact bundle for prepare and consider #605 ruled that "a second lane is a second place to be wrong" and routed everything through the single price_feed envelope for that reason. That ruling was made while Yahoo was the only source under discussion, so this issue reopens its premise rather than contradicting it — but the reasoning behind it does not weaken just because the premise changed.
• No measurement exists yet. Nobody has recorded how often Yahoo actually fails for a real review, so the benefit is asserted and the cost is known. [design·perf] Response-time budget by route — separate real-user latency from QA/test overhead #603's measure-first posture applies.

What would make this decidable

1. Measure the failure rate. How often does a real prepare/consider hit provider_missing, transport_failed, or empty_response? The gap codes already exist and are stable (market_data.GAP_CODES); nothing records them over time.
2. Decide whether a second source must agree with the first, and what happens when they disagree. A disagreement on a close is a real signal, and silently preferring one is the shape of defect this repository keeps paying for.
3. Name the normalization contract once. If a second provider lands, its closes, splits and FX have to enter through price_feed.parse exactly as a supplied envelope does — the same single lane [architecture·implementation] One market-data resolver — minimum Yahoo calls, one fact bundle for prepare and consider #605 established — rather than as a parallel adapter with its own basis rules.

Related

#629 (the agent-side recovery, this cycle's answer — proceeds independently), #605 (one resolver, one dated bundle — the ruling whose premise this reopens), #583 / #558 / #550 (the split-basis divergences that make a second normalization path expensive), #603 (measure per route before bounding it).

[atomchung]

Split out of #629 by owner ruling 2026-07-30: agent-side recovery (#629) is this cycle's answer; a second engine-side provider is a later question and does not block it.