feature_assumeutxo.py failures were a race with -fastprune 64 KiB blockfiles,
the normal chainstate can fill blk00000.dat and roll to blk00002.dat while the snapshot chainstate writes blk00001.dat before -stopatheight trips…The test now only asserts that both chainstates wrote to disk blk00000 and blk00001, tolerates blk00002.dat when it appears, and logs it. Behavior is unchanged; we just stop failing on a benign rollover..
i believe this should fix #33635
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
See the guideline for information on the review process.
| Type | Reviewers |
|---|---|
| ACK | Bortlesboat |
If your review is incorrectly listed, please copy-paste <!–meta-tag:bot-skip–> into the comment that the bot should ignore.
Signed-off-by: b-l-u-e <winnie.gitau282@gmail.com>
Was this LLM generated? What are the steps to test this? What is the output before and after the changes here?
I used claude to help with the analysis.
I couldn’t reliably reproduce the error locally each block takes many more milliseconds, so the node hits -stopatheight=359 and stops before the NORMAL chainstate fills blk00000.dat and rolls into blk00002.dat. In CI, blocks are processed much faster, so the NORMAL chainstate can create blk00002.dat before the node shuts down, which triggers the failure.
Log timestamps from CI failure vs local environment:
feature_assumeutxo_265
From node1 debug.log and test_framework.log:
18:56:47.996 – stopatheight=359 node starts
18:56:48.382 – Leaving block file 0 (onto 2) blk00002 is created
18:56:48.791 – Node stops
so blk00002 is created before the node stops roughly ~0.4 s from start to blk00002. When the test checks, it sees 3 blockfiles hence assertion fails.
assumeutxo/run_1/test_runner_₿_🏃_20260305_174948/feature_assumeutxo_0/
From node1 debug.log and test_framework.log:
15:12:02.310 – stopatheight=359 node starts
15:12:17.767 – Node stopped -> stopatheight hit; test checks blockfiles here leds to 2 files
15:12:28.194 – Leaving block file 0 (onto 2) (in node1’s debug.log, after we’ve already restarted node1)
so Node stops before blk00002 is created. The roll to blk00002 happens later during the restarted node’s background validation. Test sees only 2 files no assertion fails.
utACK b587979e57
The race between background chainstate and shutdown with -fastprune makes the third blockfile non-deterministic. Replacing the hard assertion with a log message fixes the flake while still verifying both chainstates wrote to disk.
I don’t understand this patch, it seems to just log something instead of actually testing a condition. Maybe this should be closed.
The patch still tests that both chainstates wrote to disk with assert that blk00000.dat and blk00001.dat exist. The only change is that it no longer assert the absence of blk00002.dat coz with 64 KiB blockfiles the normal chainstate can roll to a third file before -stopatheight triggers and that’s valid so when that happens just logs it.