How to reimplement bar aggregation using BarBuilder

[stastnypremysl]

Bug Report

In the given folder, there is a backtest with strategy, its output and the catalog.

Strategy tries to re-implement bar aggregation for 2 seconds and assert it against the current behavior.

The backtest runs with time_bars_skip_first_non_full_bar=True and starts exactly at 2024-12-01 00:00:00.

I also note that chunk_size = 1024*32.

Expected Behavior

The first bar is generated, as the start_time 2024-12-01 00:00:00 is dividable by 2 seconds.

Actual Behavior

The first bar is not generated.

Note

The strategy depends on the current hook ordering (the clock callbacks are called after the on_bar event). With time_bars_skip_first_non_full_bar=False, the assert works fine.

Steps to Reproduce the Problem

1. Download the data
2. Extract the zip file and change extracted catalog path in strategy.py to the catalog
3. ./strategy.py >strategy.out 2>&1
4. less strategy.out

Specifications

• OS platform: Gentoo Linux (native build, amd64)
• Python version: Python 3.12.9 (native build)
• nautilus_trader version: 1.218.0 (revision 173c1f5; make build-wheel-debug)

Additional notes

• The simulation is running on aggregated trade ticks from Binance data collection
• The instrument information was downloaded using the NT Binance client

[cjdsellers]

Hi @stastnypremysl

I see a lot of custom implementation in the strategy involving timers and the BarBuilder.
It's highly likely there is an implementation error in a strategy, rather than a bug in the clock.

When I run the strategy MRE, I also see this error:

2024-12-01T00:00:02.000000000Z [ERROR] BACKTESTER-001.BacktestNode: Error running backtest
AttributeError('BarStrategy' object has no attribute 'received_bar')

When adding this attribute, there was also an additional missing attribute error.

We can reapply the bug label and continue the investigation once confirmed with a running MRE.
For now this appears to be a question of how to reimplement bar aggregation, which I'm anticipating you need because you'd like to generate signals / update indicators based on incrementally updating bars?

[stastnypremysl]

Hi, @cjdsellers.

Thank you for the answer.

As I have written in the bug report, with time_bars_skip_first_non_full_bar=False it works. This narrow down the scope, under which is possible, there is a bug. To be more explicit, with the first bar, it works, without it, it doesn't. The first bar should be generated in my opinion in this case for the reasons written in the bug report.

This is rather a part of my testing initiative then incrementally updating bars, as we spoken before. I want to verify, that the aggregation is working fine and have it as a blackbox test to vet new versions of NT, so I can be confident enough, that new version of NT didn't brought any new hidden bug.

[cjdsellers]

Hi @stastnypremysl

I see, so the attribute error is representing the potential bug where the bar has not yet arrived.
I'll have another look, probably it comes down to the condition on which we skip that first non full bar.

[stastnypremysl]

Possible hypothesis, how this happens

The start of the backtest is delayed for some time (in the range of milliseconds) in the chunk_size>0 setup, because there is a small data hole in the beginning.

This might make aggregator think, that not the whole range of trade ticks was given for the given period at the beginning and skips the bar.

[cjdsellers]

Hi @stastnypremysl

I think thats a good theory, it might be this line here, where the condition wouldn't be true so we skip the first non full bar.

My initial impression is that this could be tricky to solve, as the backtest will begin from start but we want to retroactively simulate timers starting prior to this so that logic like the above behaves as expected.

Maybe you could figure out a solution if you're working on aggregation at the moment?

[stastnypremysl]

Hi, @cjdsellers.

As discussed in the chat, I think it might be solved by setting the clock at the start of the backtest to the original start_time given through the API. But I am not sure.