Line refs are against the registered v0.2.0 tarball.
Problem
get_range with typed=true (the default) and foreach_record's typed path require the stream to contain only the schema's record type. But historical responses can legitimately interleave other records — gateway ErrorMsg, SystemMsg, SymbolMappingMsg — and the typed reader throws on the first one:
Expected DatabentoBinaryEncoding.StatMsg (rtype=STAT_MSG) but got rtype=ERROR_MSG
Hit this pulling Schema.STATISTICS for continuous symbols on GLBX.MDP3 (the responses carried gateway error records about partial symbol resolution). The only recourse is typed=false, giving up the fast path entirely — and losing the error record's message in the process unless the caller filters for it.
Suggested fix
In the typed decode loop, when the next record header's rtype does not match the target type:
- skip the record by
hd.length (or decode it generically), rather than throwing
- surface
ErrorMsg records via @warn (they often explain why data is missing)
That keeps the fast path for the 99% case while tolerating real-world streams. Related: the underlying mis-decode that made this much worse is a DatabentoBinaryEncoding.jl bug (StatMsg layout, reported there), but interleaved system records are legitimate even with correct decoding.
Line refs are against the registered v0.2.0 tarball.
Problem
get_rangewithtyped=true(the default) andforeach_record's typed path require the stream to contain only the schema's record type. But historical responses can legitimately interleave other records — gatewayErrorMsg,SystemMsg,SymbolMappingMsg— and the typed reader throws on the first one:Hit this pulling
Schema.STATISTICSfor continuous symbols onGLBX.MDP3(the responses carried gateway error records about partial symbol resolution). The only recourse istyped=false, giving up the fast path entirely — and losing the error record's message in the process unless the caller filters for it.Suggested fix
In the typed decode loop, when the next record header's rtype does not match the target type:
hd.length(or decode it generically), rather than throwingErrorMsgrecords via@warn(they often explain why data is missing)That keeps the fast path for the 99% case while tolerating real-world streams. Related: the underlying mis-decode that made this much worse is a DatabentoBinaryEncoding.jl bug (StatMsg layout, reported there), but interleaved system records are legitimate even with correct decoding.