feature_governance.py intermittent vote/superblock assertions
Summary
feature_governance.py appears to be intermittently failing around governance
vote propagation / superblock readiness. In #7327 CI, the
linux64_sqlite-test / Test source job failed because one node only had 24
votes when the test expected all nodes to have 25.
Latest CI occurrence
Traceback excerpt:
File "test/functional/feature_governance.py", line 314, in run_test
assert_equal(node.gobject("count")["votes"], 25)
AssertionError: not(24 == 25)
The log reached:
Should see same YES and NO vote count for both triggers on all nodes now
Should have 25 votes on all nodes
then failed on the raw gobject("count")["votes"] == 25 assertion. This looks
timing/sync-sensitive: the preceding trigger Yes/No count waits had succeeded,
but the aggregate vote count was still one vote short on at least one node.
Scope check for #7327
#7327 only changes:
test/functional/feature_dip3_v19.py
test/functional/test_framework/test_framework.py
The framework change adds an optional spork_sync_timeout parameter to
activate_by_name() while keeping the existing default timeout. Neither
feature_governance.py nor its direct wait_for_sporks_same() call uses this
helper path. The modified feature_dip3_v19.py test passed in the same failing
linux64_sqlite job.
Local reproduction signal
A local develop run also showed feature_governance.py instability, though at
a later assertion:
python3 test/functional/feature_governance.py --timeout-factor=4
failed with:
File "test/functional/feature_governance.py", line 342, in run_test
self.check_superblock()
File "test/functional/feature_governance.py", line 59, in check_superblock
assert_equal(payments_found, 2)
AssertionError: not(0 == 2)
That local failure is not the same assertion, but it supports that this test is
not stable independently of #7327's DIP3 v19-only change.
Suggested next steps
- Add explicit waiting around the final aggregate
gobject("count")["votes"]
check instead of asserting immediately after per-trigger count waits; and/or
- investigate why the superblock payment assertion can fail after the earlier
governance vote checks appear to pass.
feature_governance.pyintermittent vote/superblock assertionsSummary
feature_governance.pyappears to be intermittently failing around governancevote propagation / superblock readiness. In #7327 CI, the
linux64_sqlite-test / Test sourcejob failed because one node only had 24votes when the test expected all nodes to have 25.
Latest CI occurrence
test: extend v19 spork sync wait)fb832662467a241a70c97826d2d3863bd44858f1v23.1.xhttps://github.com/dashpay/dash/actions/runs/26015843317/job/76468743126
linux64_sqlite-test / Test sourcefeature_governance.pyTraceback excerpt:
The log reached:
then failed on the raw
gobject("count")["votes"] == 25assertion. This lookstiming/sync-sensitive: the preceding trigger Yes/No count waits had succeeded,
but the aggregate vote count was still one vote short on at least one node.
Scope check for #7327
#7327 only changes:
The framework change adds an optional
spork_sync_timeoutparameter toactivate_by_name()while keeping the existing default timeout. Neitherfeature_governance.pynor its directwait_for_sporks_same()call uses thishelper path. The modified
feature_dip3_v19.pytest passed in the same failinglinux64_sqlitejob.Local reproduction signal
A local
developrun also showedfeature_governance.pyinstability, though ata later assertion:
failed with:
That local failure is not the same assertion, but it supports that this test is
not stable independently of #7327's DIP3 v19-only change.
Suggested next steps
gobject("count")["votes"]check instead of asserting immediately after per-trigger count waits; and/or
governance vote checks appear to pass.