AddFuture() silently no-ops when the same ticker is added twice with different DataMappingMode, breaking History()

[AlexCatarino]

Summary

History() requests against the continuous-contract (canonical) Symbol for four
International Futures (TickData) tickers return zero rows, for every
DataMappingMode, while an otherwise-identical request for a fifth ticker in the
same dataset returns full results.

Repro

• Tickers tried: FESX (Eurex), FDAX (Eurex), HSI (HKFE), KM (KRX) — all
  empty.
• Control: NKD (CME) — same code pattern, same call — works, returns full
  history.
• Both DataMappingMode.OPEN_INTEREST and DataMappingMode.LAST_TRADING_DAY
  were tried on all five tickers; mapping mode makes no difference to the
  empty/non-empty outcome.
• Request shape: History() for the continuous/canonical future symbol,
  daily resolution, ~1300 bars, ending at present.

A reproduction backtest is available: reporter's project
https://www.quantconnect.com/project/35772671/937ad4bb9a51c1df7694b7a8e9a82f23
(not accessible to us — reporter's own project; a human with org access should
pull it for the exact algorithm).

What we ruled out (cloud data store, confirmed present for all four "empty" tickers)

Checked directly against the cloud data store (/data/list), not from
documentation:

• future/eurex/universes/fesx/ — universe files present from 1998-07-22
  through the most recent trading session (2026-08-27).
• future/eurex/universes/fdax/ — present from 2010-01-25 through 2026-08-27.
• future/hkfe/universes/hsi/ — present from 2010-01-25 through 2026-08-27.
• future/krx/universes/km/ — present from 2013-11-12 through 2026-08-26.
• future/eurex/map_files/, future/hkfe/map_files/, future/krx/map_files/
  all have a current map-file snapshot dated 2026-08-2x.
• Raw trade/quote/open-interest files for these tickers are present and
  up to date (spot-checked FESX and HSI directly).

So this is not a case of the underlying files being absent — the History
request itself returns nothing for these four tickers specifically.

Possible lead (unconfirmed — flagging as an open question, not asserted root cause)

The one dimension separating the four "empty" tickers from the one "working"
ticker is exchange / time zone: FESX/FDAX (Eurex, Europe/Berlin), HSI
(HKFE, Asia/Hong_Kong), KM (KRX, Asia/Seoul) are all "empty"; NKD,
despite also being a non-US index product, is listed under Market.CME with
America/Chicago and is the one that works. Worth checking whether continuous
contract History resolution has a market/time-zone-scoped code path that
doesn't cover Eurex/HKFE/KRX futures. We have not traced this into the LEAN
history-provider code, so treat it as a hint for triage rather than a diagnosis.

Reference

Internal ticket: Intercom conversation 215475691979456.

[AlexCatarino]

Root cause found — narrower than the time-zone lead above

The reporter's repro added the same ticker under two different DataMappingModes in one algorithm (e.g. AddFuture("FESX", dataMappingMode: OpenInterest) then AddFuture("FESX", dataMappingMode: LastTradingDay)) to compare them side by side. That collides silently:

• ContinuousContractUniverse.CreateSymbol(Symbol) (Common/Data/UniverseSelection/ContinuousContractUniverse.cs:158-162) keys the continuous universe as qc-universe-continuous-{market}-{securityType}-{ticker} — no DataMappingMode component.
• QCAlgorithm.AddSecurity (Algorithm/QCAlgorithm.cs:2055) guards with if (!UniverseManager.ContainsKey(symbol)), so the second AddFuture call for the same ticker+market skips creating a second universe entirely.
• Even past that guard, UniverseManager.Add (Common/Securities/UniverseManager.cs:59-68) uses Dictionary.TryAdd, silently dropping the duplicate key — by a comment in the source, this is by design for the general duplicate-universe case, not a check against same-ticker/different-mode specifically.

Net effect: the second AddFuture call for a given ticker is a silent no-op, and History() against the resulting Symbol can come back empty depending on which mapping mode's request LEAN actually resolves against the single surviving universe. This reproduces regardless of exchange/time zone — the reporter's own control (NKD, tested without the same-ticker/dual-mode pattern) worked precisely because it wasn't added twice.

The exchange/time-zone correlation noted above (Eurex/HKFE/KRX empty, CME NKD fine) was circumstantial: the reporter happened to test the four International Futures tickers with the dual-mode side-by-side pattern and NKD without it, not a Eurex/HKFE/KRX-specific defect. Confirmed working once he stopped adding the same ticker under two mapping modes in one algorithm.

Suggest re-scoping this issue to: AddFuture silently no-ops (no exception, no log) when called twice for the same ticker+market with different DataMappingModes, instead of raising or supporting both. At minimum this should throw/log rather than silently return empty history for one of the two requested modes.