Bug Report

Setup

CometBFT version (use cometbft version or git rev-parse --verify HEAD if installed from source):

main , v0.38.x-experimental

Have you tried the latest version: yes

ABCI app (name for built-in, URL for self-written if it's publicly available):

Environment:

• OS (e.g. from /etc/os-release):
• Install tools:
• Others:

node command runtime flags:

Config

What happened?

We noticed this test failure frequently in CI : https://github.com/cometbft/cometbft/actions/runs/6495267396/job/17639883516?pr=1474#step:5:108 .
The particular test (TestPruningService within store/store_test.go ) tests whether pruning is triggered when both the data companion and the application set different retain heights.

Before reaching line 668, the application and the data companion have set their retain heights so that all blocks up to height 1200 were pruned.

In line 668 , the retain height set by the application (1300) should be ignored because the data companion's retain height is still set to 1200.

Due to this, no pruning should happen until line 668 and we would expect the observer to be notified only when pruning actually happens. That is why the condition on line 676 assumes that the base height of the store is now the one set by the application in L668.

When the data companion increases its retain height to 1350 in line 671, 1300 is the lowest of the two and the pruning service can now prune blocks up to height 1300.

However, the pruning routine of the pruner is restarted before the code in line 671 is executed, no pruning is performed but the observer is notified, the pruning service sleeps for the duration of pruningInterval and the test reaches the check in line 676.

At that point the base value of the store is still 1200 as the pruning service did not realize the change in retain heights.

What did you expect to happen?

The observer should not have been notified of the new retain height in case no pruning happens. Therefore the test should wait on a new value on the observer channel until the pruning service wakes up and realizes that blocks up to 1300 can be pruned.

How to reproduce it

The failure can be reproduced locally by setting the pruning interval to a very low value (1 millisecond for example). This will trigger the pruning service to start before the new retain height is set.