on_book_deltas parity between live and backtest

[Harsh-Maheshwari]

• Live: nautilus's Binance adapter (crates/adapters/binance/src/futures/websocket/streams/parse_data.rs:190-245)
  parses one Binance depthUpdate WS message into a Vec covering every bid+ask entry in that message, flags only the last one with RecordFlag::F_LAST, and wraps the whole thing into one OrderBookDeltas. The data engine (crates/data/src/engine/mod.rs:2468-2489) dispatches that as one on_book_deltas call. If deltas arrive individually and buffer_deltas is on, the engine buffers them itself and only publishes once it sees F_LAST

• Backtest/catalog replay: OrderBookDelta (the individual item) is what has an Arrow encode/decode impl — the OrderBookDeltas container has none. So the compacted Parquet catalog stores one row per delta, and replaying it reconstructs one OrderBookDeltas-of-exactly-one per row

• Is this difference in behaviour a feature or a bug? I would have assumed that the backtest replay would also batch the updates for a single F_LAST and this would provide live/backtest parity

• If any calculation is done inside on_book_deltas it will be duplicated multiple times in a backtest (giving us partial changed results as the order book would differ after every update from the same nanosecond updates) while it will only run once in live (the correct way is of live)

[cjdsellers]

Hi @Harsh-Maheshwari,

Thanks for raising this. You're right about the expected behavior: we want backtest/live parity, including the event boundaries visible to a strategy. This gap has come up before and remains outstanding as part of the V2 transition and catalog work.

As you noted, the data engine already supports buffering through F_LAST. That currently defaults to off, so buffer_deltas=True is worth checking for callback batching. There is a broader concern though: the backtest sends individual deltas to the simulated exchange before the data engine buffers them, so that setting alone doesn't establish parity for matching against the book.

For deltas stored as flat, unbatched rows, I think the likely direction is a backtest data client that reconstructs the batches an adapter such as Binance would deliver. This would move the reconstruction further upstream in the backtest flow, before both simulated exchange processing and strategy delivery, then feed those OrderBookDeltas directly through the engine. There may also be support for streaming OrderBookDeltas batches directly from the catalog. Either path needs to preserve the recorded event boundaries rather than group solely by timestamp or catalog read chunk.

That still allows us to keep individual delta rows on disk, with their ordering and F_LAST flags preserved. We don't need nested delta containers in storage to reconstruct the original events. #4959 adds typed catalog batches and streaming query changes, but retains the existing replay model, so it doesn't resolve this by itself. It provides related groundwork for the next step.