FB-012: get_instrument_data has no expiry filter and no dedupe; rows collide silently [silent-wrong, latent]
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 48/100
Direzione di ricerca
Start in data.py at DuckDBVortexLoader.get_instrument_data (line 303) and compare its row selection and data[time_str] assignment with get_underlying_data (line 273). Trace how the context supplies instrument data and inspect the relevant duplicate and multiple-expiry cases described in the issue. Done means the optional expiry filter is passed through and duplicate keys are handled predictably, with tests covering conflicting rows.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Severity: silent-wrong (latent) · Source: BUGS_FASTBT.md (2026-10-12; consolidation E002 2026-10-11)
DuckDBVortexLoader.get_instrument_data (data.py:303) selects on trade_date, option_type and strike only, and builds data[time_str] = row. If a date has two rows for one strike and minute, the later row overwrites the earlier one with no warning. ORDER BY trade_time does not order ties, so which row wins is arbitrary. Triggers:
- duplicate rows in the file (
nifty_full.vortex, 2026-03-24..04-30) - more than one expiry on a date (merged weekly + next-week or monthly file)
get_underlying_data (data.py:273) has the same pattern with SELECT DISTINCT trade_time, underlying_price: two different prices for one minute give two rows, and the later one wins.
Today's results are not affected (consolidation E002 ran 4 strategy configs on original vs deduped copy, default and 1-thread DuckDB — identical trades; holds only because duplicate copies are byte-identical and every current file has one expiry per date).
Workaround: keep one expiry per file, and dedupe any new file before use.
Fix: take an optional expiry in get_instrument_data (pass it from the context), and either dedupe on (trade_time, expiry, strike, option_type) or raise when a key appears twice with different values.
- Lingua principale
- Python
- Stelle
- 28
- Fork
- 17
- Merge medio
- 8h 50m
- PR unite (30g)
- 2
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di uberdeveloper/fastbt
-
bug
Difficoltà 4/5 3-5 giorni Idoneità per principianti 52/100
uberdeveloper/fastbt#30 ·
-
bug
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
uberdeveloper/fastbt#28 ·
-
FB-008: close_trade mixes price and tick; stale exits are silent (zero-P&L fallback) [silent-wrong]Apertabug
Difficoltà 3/5 1-2 giorni Idoneità per principianti 70/100
uberdeveloper/fastbt#27 ·
-
bug
Difficoltà 3/5 1-2 giorni Idoneità per principianti 55/100
uberdeveloper/fastbt#26 ·
-
bug
Difficoltà 3/5 1-2 giorni Idoneità per principianti 56/100
uberdeveloper/fastbt#25 ·
Tutte le issue di uberdeveloper/fastbt
Issue simili
-
`burr` fails to start when the Python path has a space in itForse già presa @enekoreto l’ha presa oggi. Apertastatus/needs-triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 5 giorni
-
gemini 出现了新的域名需要加入Aperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 72/100
-
Difficoltà 2/5 Mezza giornata Idoneità per principianti 72/100
debpalash/VoiceStudio#2903 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
dagster-io/community-integrations#367 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
aws-samples/sample-per-model-bedrock#243 ·
I maintainer di solito rispondono entro 1 giorno