FillModel derived extensions do not "walk the order book" when using bars data

[idobz]

Bug Report

Confirmation

Before opening a bug report, please confirm:

• [v] I’ve re-read the relevant sections of the documentation.
• [v] I’ve searched existing issues and discussions to avoid duplicates.
• [v] I’ve reviewed or skimmed the source code (or examples) to confirm the behavior is not by design.
• [v] I’ve tested this issue using a recent development wheel (dev develop or a nightly) and can still reproduce it.

Expected Behavior

The expected behavior when using, for example, the OneTickSlippage FillModel, is for market orders to be fulfilled (putting aside the question of price).

Actual Behavior

The actual behavior is that market orders are not fulfilled when the order book - as defined by the fill model - does not contain 'best_bid`/'best_sell' price BookOrder has 0 quantity

Steps to Reproduce the Problem

Untar attached tar file. It contains a python file (with strategy and main), and a small catalog.
Run the python code using an environment that has NT installed (note the version used)

When run with FILL_MODEL = "Standard" (the default setting in row 26) the orders get filled
When run with FILL_MODEL = "OneTickSlippage" (row 27) the orders are not filled.

Code Snippets or Logs

Specifications

• OS platform: Ubuntu
• Python version: 3.12.7
• nautilus_trader version: 1.221.0a20250921

fillmodel.tar.gz

[cjdsellers]

Thanks for the thoughts and write up @idobz

Now fixed from #3039.

[idobz]

Hi @cjdsellers, Will keep this channel open for a little longer, as I try to push through with the IB/Nautilus paper trading scenario. Hope that's ok Some comments: 1. I manually place venue=None to circumvent the issues with this. Not sure what is lost by this, as I still manage to buy and sell 2. I often get these errors: 2025-10-07T16:05:00.043941909Z [WARN] IB_LIVE-001.CX_spread: Order submitted: STOP_MARKET BUY CX 2025-10-07 16:05:00.009618458 current close: 9.065 2025-10-07T16:05:00.044863154Z [WARN] IB_LIVE-001.InteractiveBrokersClient-062: The price does not conform to the minimum price variation for this contract. (code: 110, req_id=142) 2025-10-07T16:05:00.044881553Z [WARN] IB_LIVE-001.InteractiveBrokersClient-062: Unhandled order warning or error code: 110 (req_id 142) - The price does not conform to the minimum price variation for this contract. despite the fact that I use trigger_price=self.instrument.make_price( curr_bar.close.as_double() * 1.005 ) which, as I understand it, should set the correct price variation 3. when I stop the node, and then restart it - overall the DB seems to perform well, but I do get these errors: 2025-10-07T16:53:41.557877140Z [ERROR] IB_LIVE-001.ExecEngine: Error on applying OrderFilled(trader_id=IB_LIVE-001, strategy_id=BF_B_spread-023, instrument_id=BF-B.NYSE, client_order_id=O-20251007-153000-001-023-1, venue_order_id=102, account_id=INTERACTIVE_BROKERS-DUM955954, trade_id=0000e0d5.68e5e7f8.01.01, position_id=BF-B.NYSE-BF_B_spread-023, order_side=BUY, order_type=STOP_MARKET, last_qty=5, last_px=27.91 USD, commission=1.00 USD, liquidity_side=NO_LIQUIDITY_SIDE, event_id=0ba5a0e6-1662-49d3-a997-0edc35ff3331, ts_event=1759855750000000000, ts_init=1759856021557509242) to Position(LONG 5 BF-B.NYSE, id=BF-B.NYSE-BF_B_spread-023) KeyError("Duplicate TradeId('0000e0d5.68e5e7f8.01.01') in events OrderFilled(instrument_id=BF-B.NYSE, client_order_id=O-20251007-153000-001-023-1, venue_order_id=102, account_id=INTERACTIVE_BROKERS-DUM955954, trade_id=0000e0d5.68e5e7f8.01.01, position_id=BF-B.NYSE-BF_B_spread-023, order_side=BUY, order_type=STOP_MARKET, last_qty=5, last_px=27.91 USD, commission=1.00 USD, liquidity_side=NO_LIQUIDITY_SIDE, ts_event=1759855750000000000) OrderFilled(instrument_id=BF-B.NYSE, client_order_id=O-20251007-153000-001-023-1, venue_order_id=102, account_id=INTERACTIVE_BROKERS-DUM955954, trade_id=0000e0d5.68e5e7f8.01.01, position_id=BF-B.NYSE-BF_B_spread-023, order_side=BUY, order_type=STOP_MARKET, last_qty=5, last_px=27.91 USD, commission=1.00 USD, liquidity_side=NO_LIQUIDITY_SIDE, ts_event=1759855750000000000)") Traceback (most recent call last): File "nautilus_trader/execution/engine.pyx", line 1499, in nautilus_trader.execution.engine.ExecutionEngine._update_position File "nautilus_trader/model/position.pyx", line 489, in nautilus_trader.model.position.Position.apply File "nautilus_trader/model/position.pyx", line 690, in nautilus_trader.model.position.Position._check_duplicate_trade_id 4. I cancel all in flight orders before stopping the node - otherwise I get very ugly errors (and once a core dump) as I try to restart again.

…

On Oct 7, 2025, at 7:17 AM, Chris Sellers ***@***.***> wrote: cjdsellers left a comment (nautechsystems/nautilus_trader#3031) <#3031 (comment)> Thanks for the thoughts and write up @idobz <https://github.com/idobz> Now fixed from #3039 <#3039>. — Reply to this email directly, view it on GitHub <#3031 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABWKHMTRNZ7E53N475G2DWT3WM5GZAVCNFSM6AAAAACII2IH62VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGNZVGEZTGMJYGA>. You are receiving this because you were mentioned.

[cjdsellers]

Hi @idobz

Thanks for the feedback there, a few things to unpack:

1. There might be some issue with instrument parsing for IB. Whatever price increment is being used doesn't seem to match the instrument definition on the IB side. Could you share the specific instrument/contract details? this might be worth raising a separate issue for.
2. The duplicate trade ID protection is working correctly, but the underlying issue is that fills are being replayed unnecessarily on restart. This should be fixed with the reconciliation improvements (explained below).
3. There's an interaction here between previously cached state and information back from the venue, with the diff not being well handled by the looks of it.

Since this GH issue relates to fill models in backtesting, I'll raise a more specific one for these reconciliation issues. There is actually a separate branch reconciliation which has upgraded a few things (such as improved average entry price calculations and proper lifecycle reconstruction for positions). The plan is to merge this some time after the next release (imminent / days).

In the meantime, your workaround of canceling in-flight orders before shutdown should prevent the most critical issues.

[idobz]

Thanks for all of this very useful information @cjdsellers I looked into the price increment issue for instruments. The instruments I had trouble with were CX and GFI (and maybe others too). I think that it is not an NT issue, but a BK one. The IBContract, or whatever structure is returned by the IB client, says that tick size is 0.0001 This very old stack overflow describes a conversation with IB reps about this (TLDR - the API cannot be trusted) https://stackoverflow.com/questions/30375358/issues-reading-mintick-from-interactive-brokers-java-api My 2 cents are that when there are multiple possible increments (as described by the contract details page in IB website), only the first one (0.0001) is picked by the IB API - and in my case it was only relevant for fractional shares in both stocks that I checked. Whole stocks go with 0.01. I'll refrain from using make_price for the time being. It looks like most stocks will go with 0.01 when not fractional. Looking forward to that reconciliation branch reaching develop!! LMK if I can help (but I'm more of a programmer than a trader - don't understand options and all of that clever stuff)

…

On Oct 8, 2025, at 3:12 AM, Chris Sellers ***@***.***> wrote: cjdsellers left a comment (nautechsystems/nautilus_trader#3031) <#3031 (comment)> Hi @idobz <https://github.com/idobz> Thanks for the feedback there, a few things to unpack: There might be some issue with instrument parsing for IB. Whatever price increment is being used doesn't seem to match the instrument definition on the IB side. Could you share the specific instrument/contract details? this might be worth raising a separate issue for. The duplicate trade ID protection is working correctly, but the underlying issue is that fills are being replayed unnecessarily on restart. This should be fixed with the reconciliation improvements (explained below). There's an interaction here between previously cached state and information back from the venue, with the diff not being well handled by the looks of it. Since this GH issue relates to fill models in backtesting, I'll raise a more specific one for these reconciliation issues. There is actually a separate branch reconciliation which has upgraded a few things (such as improved average entry price calculations and proper lifecycle reconstruction for positions). The plan is to merge this some time after the next release (imminent / days). In the meantime, your workaround of canceling in-flight orders before shutdown should prevent the most critical issues. — Reply to this email directly, view it on GitHub <#3031 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABWKHMVAR7BGQEZ7PXQDSZL3WRJH5AVCNFSM6AAAAACII2IH62VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGNZZGEYTGNJWGY>. You are receiving this because you were mentioned.

[idobz]

I hope that I'm not a pain in the ass, but I fear that your solution to the flat positions in the IB client is incomplete. Back when I tried to fix this myself, I was getting contrary simultaneously opened positions (in a netting account) that would sum to 0. I was wondering how you managed to sidestep this, and I now see that it wasn't sidestepped: 2025-10-08T14:28:27.213825095Z [WARN] IB_LIVE-001.Cache: Residual Position(SHORT 4 AGI.NYSE, id=AGI.NYSE-AGI_spread-010) 2025-10-08T14:28:27.213832922Z [WARN] IB_LIVE-001.Cache: Residual Position(LONG 4 AGI.NYSE, id=AGI.NYSE-EXTERNAL) 2025-10-08T14:28:27.213838694Z [WARN] IB_LIVE-001.Cache: Residual Position(SHORT 13 ASX.NYSE, id=ASX.NYSE-ASX_spread-004) 2025-10-08T14:28:27.213843482Z [WARN] IB_LIVE-001.Cache: Residual Position(LONG 13 ASX.NYSE, id=ASX.NYSE-EXTERNAL) 2025-10-08T14:28:27.213848104Z [WARN] IB_LIVE-001.Cache: Residual Position(LONG 5 B.NYSE, id=B.NYSE-EXTERNAL) 2025-10-08T14:28:27.213852904Z [WARN] IB_LIVE-001.Cache: Residual Position(SHORT 5 B.NYSE, id=B.NYSE-INTERNAL-DIFF) 2025-10-08T14:28:27.213857613Z [WARN] IB_LIVE-001.Cache: Residual Position(SHORT 5 CCL.NYSE, id=CCL.NYSE-CCL_spread-017) 2025-10-08T14:28:27.213862030Z [WARN] IB_LIVE-001.Cache: Residual Position(LONG 5 CCL.NYSE, id=CCL.NYSE-EXTERNAL) etc etc In the actual account none of these are current positions - they've all been closed My debugging session seemed to show that NT does not manage this because of the different strategy names @cjdsellers

…

On Oct 8, 2025, at 5:01 PM, Ido Ben-Zvi ***@***.***> wrote: Thanks for all of this very useful information @cjdsellers I looked into the price increment issue for instruments. The instruments I had trouble with were CX and GFI (and maybe others too). I think that it is not an NT issue, but a BK one. The IBContract, or whatever structure is returned by the IB client, says that tick size is 0.0001 This very old stack overflow describes a conversation with IB reps about this (TLDR - the API cannot be trusted) https://stackoverflow.com/questions/30375358/issues-reading-mintick-from-interactive-brokers-java-api My 2 cents are that when there are multiple possible increments (as described by the contract details page in IB website), only the first one (0.0001) is picked by the IB API - and in my case it was only relevant for fractional shares in both stocks that I checked. Whole stocks go with 0.01. I'll refrain from using make_price for the time being. It looks like most stocks will go with 0.01 when not fractional. Looking forward to that reconciliation branch reaching develop!! LMK if I can help (but I'm more of a programmer than a trader - don't understand options and all of that clever stuff) > On Oct 8, 2025, at 3:12 AM, Chris Sellers ***@***.***> wrote: > > > cjdsellers > left a comment > (nautechsystems/nautilus_trader#3031) > <#3031 (comment)> > Hi @idobz <https://github.com/idobz> > Thanks for the feedback there, a few things to unpack: > > There might be some issue with instrument parsing for IB. Whatever price increment is being used doesn't seem to match the instrument definition on the IB side. Could you share the specific instrument/contract details? this might be worth raising a separate issue for. > The duplicate trade ID protection is working correctly, but the underlying issue is that fills are being replayed unnecessarily on restart. This should be fixed with the reconciliation improvements (explained below). > There's an interaction here between previously cached state and information back from the venue, with the diff not being well handled by the looks of it. > Since this GH issue relates to fill models in backtesting, I'll raise a more specific one for these reconciliation issues. There is actually a separate branch reconciliation which has upgraded a few things (such as improved average entry price calculations and proper lifecycle reconstruction for positions). The plan is to merge this some time after the next release (imminent / days). > > In the meantime, your workaround of canceling in-flight orders before shutdown should prevent the most critical issues. > > — > Reply to this email directly, view it on GitHub <#3031 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABWKHMVAR7BGQEZ7PXQDSZL3WRJH5AVCNFSM6AAAAACII2IH62VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGNZZGEYTGNJWGY>. > You are receiving this because you were mentioned. >

[faysou]

https://github.com/nautechsystems/nautilus_trader/blob/develop/examples/backtest/notebooks/databento_option_greeks.py#L67

Look here for the tick scheme

[idobz]

Looks like this is what is needed - except that AFAIK it would need to be filled manually for certain instruments - the TWS API does not report the full scheme

[faysou]

Yes, you can do manually like in my example, it would work in live as well.