Issues tracker

Submit issue and bug reports here. For feature requests and enhancements, use our Roadmap instead. For other issues, or if you prefer to reach us privately, contact support.

Trending
  1. Incorrect scaling of strike price in definition schema for some CME options

    Gold (OG.OPT) option strike prices are 100x too small and silver option (SO.OPT) strike prices are 10x too small. Corresponds with issue D-2171.

    Carter Green
    #data-quality

    0

  2. Extend Nasdaq coverage to include last hour of extended trading, when it crosses into next UTC day

    During winter months, when Eastern Time is UTC-4, the last hour of Nasdaq extended trading session (7 to 8pm ET) extends into the following UTC day. This is assigned D-2127 internally.

    Jack C

    0

  3. Saturday test data shows up on CME live data

    Currently our historical data discards Saturday test data on CME, however our live data gateways expose the test data because it’s useful for Databento’s own internal monitoring to ensure that our live gateways are running properly. We plan to discard this test data in live as well to ensure point-in-time behavior. We’ll likely have to hide test data from customers. This is assigned D-2036 internally and will likely only be addressed in Q3.

    Tessa Hollinger
    #bug#data-quality

    0

  4. MDOrderPriority is not provided for CME Globex MDP 3.0

    We currently leave out MDOrderPriority from our normalized MBO messages, due to 2 reasons: This behavior is CME-specific. Most other venues adopt ITCH-based behavior, where ordering is based on timestamp instead. If we supported MDOrderPriority, it would bloat the data for all of the non-CME venues. ts_event serves the same purpose as MDOrderPriority for all instruments except for interest rate options and instruments where there's a LMM. We confirmed this with CME GCC and also from practical experience of comparing simulation against live order matching. We actually recommend most users to infer MDOrderPriority from ts_event since it makes their order book implementation more reusable for other venues. Two proposed solutions were considered: Exposing raw message payloads and PCAPs. 'Supplementing' our normalized MBO data with venue-specific fields. We consider approach 2 to be inferior: If we tried incorporating other fields, we'd be replicating the venue's original structure in DBN with unnecessary indirection and copies and losing the benefit of normalization β€” so we might as well expose the raw message payload. For many venues, the raw data has nested message tree structures, and if we replicated it, either in Databento Binary Encoding or an unstructured encoding like JSON, we'd lose a lot of the benefits of our zero-copy binary encoding. The only limitation of approach 1 is that it's bandwidth-intensive, obviously as most venues require you to receive their raw multicast data on their extranet over a physical cross-connect. At this time, we reject approach 2 and are working towards approach 1. This is tracked on our roadmap here. This is tracked internally as D-2130.

    Tessa Hollinger
    #http-api πŸ”—#raw-api πŸ”—

    1

  5. ICE Europe live subscription returns data for a select few symbols only

    Live subscription for Brent Crude futures and spreads is not returning any messages for futures and spreads towards the front of the curve. The few messages that are being returned are for really illiquid contracts way out in the curve. As of now, messages being returned are for the June 24/Dec 30 and Dec 24/Dec 30 spread and a few more spreads which are not even trading. No messages for the front months are being returned. Code used to test: def print_record(rec: DBNRecord): print(rec) def test_live(): ice_live_client = db.Live(key=constants.DATABENTO_API_KEY) ice_live_client.subscribe( dataset="IFEU.IMPACT", schema=Schema.MBO, stype_in=SType.PARENT, symbols="BRN.FUT" ) ice_live_client.add_callback(print_record) ice_live_client.start() ice_live_client.block_for_close(timeout=None)

    Ashish P
    #bug#python πŸ”—

    1

  6. Fututes series not not working?

    Trying to retrieve the following data set : params = dict( symbols='SR3.c.0', dataset='GLBX.MDP3', schema='ohlcv-1d', stype_in='continuous', start= '2017-06-01', end='2024-02-29', ) receiving the following error: databento.common.error.BentoError: Error streaming response: Response ended prematurely

    James
    #raw-api πŸ”—#python πŸ”—#performance

    0

  7. Using standard Databento credentials for FTP subjects those credentials to sniffing

    This is related to: https://roadmap.databento.com/b/n0o5prm6/feature-ideas/support-more-secure-ftp This is assigned D-2126 internally and we plan to addressing this in Q2 2024.

    Tessa Hollinger
    #security

    0

  8. MBP-1/10 `side` field is only filled in for Trades

    Our MBP-1/MBP-10 schemas currently only provide side information on trades (to indicate the aggressing side).

    Renan G

    6

  9. CME Statistics: sequence field uses RptSeq instead of MsgSeqNum

    In the GLBX.MDP3 dataset (CME), the statistics schema uses the incorrect field from CME to populate the sequence number. This is assigned D-1651 internally

    Zach Banks
    #bug#data-quality

    1

  10. Leg information is not provided for composite instruments in CME and ICE

    Currently, the InstrumentDefMsg provided by our definition schema does not contain the underlying leg information. This is assigned internal ticket D-2032.

    Renan Gemignani
    #symbology

    0

  11. Unable to include previous day (Saturday) in API and frontend request on Sunday

    Usually, you'd be able to request data from T-1 as soon as it becomes available. It appears that on Sunday (e.g. 11/19), T-1 is Saturday (11/18), and currently our API and frontend prevents you from getting 11/18 until 11/19 is released, therefore causing an artificial wait time of an extra day before you can include 11/18 in your API or frontend request. This is purely an ergonomic issue since Saturday would have no data, but it does create some pain in the integration experience.

    Tessa Hollinger
    #bug#http-api πŸ”—#portal πŸ–₯

    1

  12. DBN files from split batch jobs have symbology for the whole time range

    If a batch job has a "split duration" set, then each DBN file only covers a subset of dates of the original job. (This holds true regardless of "split symbols" or "split size" settings.) Currently, the symbology metadata included in each DBN file from the batch job still covers the entire batch job's time range, not the subset of time that the DBN file is for (e.g. the 1 day or 1 week). With "split by date," each entry in the symbology metadata in the DBN file should only have 1 interval which should cover exactly 1 day. There should be no overlap of instrument_ids. /timeseries.get_range is not impacted by this, since it doesn't have the "split duration" concept.

    Zach Banks
    #bug#symbology

    0

  13. Nasdaq TotalView ITCH data issues

    We have degraded data on: 2020-06-22 2021-07-07 2021-10-26 2022-09-19 We'll be backfilling these. These issues are also reported via the metadata.get_dataset_condition endpoint. This is assigned D-456 internally.

    Tessa Hollinger
    #data-quality#data-gap#http-api πŸ”—

    0

  14. Degraded data on GLBX.MDP3 for 2020-02-27, 2020-02-28, 2020-06-30, 2020-07-01

    GapsΒ have been reported at the start of 2020-07-01, but underlying the issue is because of the captures for the previous day (2020-06-30), which stopped around 16:30Z (missing ~8 hrs).

    Tessa Hollinger
    #data-quality#data-gap

    4

  15. F_MAYBE_BAD_BOOK set on GLBX.MDP3 records on most Sundays

    When streaming MBO or MBP-n data from GLBX.MDP3, the F_MAYBE_BAD_BOOK flag is set during most Sundays. This flag normally indicates that there was packet loss and a gap in the data, so we are uncertain of the definitive state of the book. However, these cases have been confirmed to be entirely false positives: no data has been missed, the book state is OK. This is assigned D-1883 internally.

    Zach Banks
    #bug#data-quality#data-gap

    1