Problem
req_contract_details does not return a usable result for a non-stock contract. A stock resolves normally; a future returns one month, twice; an option returns nothing at all, with no error either.
Measured against a live paper session:
| request |
rows returned |
SPY STK SMART |
27, one per listing exchange |
MES FUT CME, no month named |
["202709:893091670", "202709:893091670"] |
MES FUT CME, month named 202609 |
["202609:793356217", "202609:793356217"] |
SPY OPT SMART, several expiry and strike combinations |
none, and no error |
Two separate defects.
A futures symbol returns a single month, duplicated. MES lists five quarterly contracts. Asking for the symbol should return the chain, which is how a caller discovers what is listed; instead one contract comes back twice. Worse, the one returned when no month is named is the furthest out, so a caller who takes the first row gets a contract with almost no book. Naming the month explicitly does resolve the right contract, so the request itself works and it is the reply handling that loses the rest.
An option returns nothing, and nothing is not an error. The request goes out with the identity on it:
35=c|320=1|321=2|55=SPY|167=OPT|200=20260821|201=1|202=800|231=100|100=BEST|15=USD
201=1 is the documented code for a call on this dialect, 202 and 231 carry the strike and multiplier, and the same shape resolves a future. No contract_details row arrives and no error either, so a caller waits out its own timeout with nothing to report. Compare an unresolvable stock, which correctly answers No security definition has been found for the request — so the not-found path itself works and this is not reaching it.
Impact
Options cannot be traded at all, because a contract that cannot be resolved cannot be ordered: the caller has no conId and no way to confirm the contract it is about to trade. Futures can be traded only by a caller that already knows the exact contract month, since discovery returns one arbitrary month rather than the chain.
Order encoding is not the blocker here. A future placed against an explicitly named month is accepted and works — limit, stop, stop limit, market-if-touched, market-to-limit and trailing stop limit all acknowledge on MES 202609. It is discovery that is missing.
Suggestion
Handle the reply fan-out for a non-stock request the way the stock path already does, and make the empty case take the same not-found route an unresolvable stock takes, so a caller gets an answer rather than a timeout.
Problem
req_contract_detailsdoes not return a usable result for a non-stock contract. A stock resolves normally; a future returns one month, twice; an option returns nothing at all, with no error either.Measured against a live paper session:
SPYSTK SMARTMESFUT CME, no month named["202709:893091670", "202709:893091670"]MESFUT CME, month named202609["202609:793356217", "202609:793356217"]SPYOPT SMART, several expiry and strike combinationsTwo separate defects.
A futures symbol returns a single month, duplicated. MES lists five quarterly contracts. Asking for the symbol should return the chain, which is how a caller discovers what is listed; instead one contract comes back twice. Worse, the one returned when no month is named is the furthest out, so a caller who takes the first row gets a contract with almost no book. Naming the month explicitly does resolve the right contract, so the request itself works and it is the reply handling that loses the rest.
An option returns nothing, and nothing is not an error. The request goes out with the identity on it:
201=1is the documented code for a call on this dialect,202and231carry the strike and multiplier, and the same shape resolves a future. Nocontract_detailsrow arrives and noerroreither, so a caller waits out its own timeout with nothing to report. Compare an unresolvable stock, which correctly answersNo security definition has been found for the request— so the not-found path itself works and this is not reaching it.Impact
Options cannot be traded at all, because a contract that cannot be resolved cannot be ordered: the caller has no conId and no way to confirm the contract it is about to trade. Futures can be traded only by a caller that already knows the exact contract month, since discovery returns one arbitrary month rather than the chain.
Order encoding is not the blocker here. A future placed against an explicitly named month is accepted and works — limit, stop, stop limit, market-if-touched, market-to-limit and trailing stop limit all acknowledge on
MES 202609. It is discovery that is missing.Suggestion
Handle the reply fan-out for a non-stock request the way the stock path already does, and make the empty case take the same not-found route an unresolvable stock takes, so a caller gets an answer rather than a timeout.