Repository navigation
test: feature_governance.py intermittent vote/superblock assertions #7328
Description
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
- PR: test: extend v19 spork sync wait #7327 (
test: extend v19 spork sync wait) - PR head:
fb832662467a241a70c97826d2d3863bd44858f1 - Base:
v23.1.x - Failing run/job:
https://github.com/dashpay/dash/actions/runs/26015843317/job/76468743126 - Failing check:
linux64_sqlite-test / Test source - Failing test:
feature_governance.py
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=4failed 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.
Activity
thepastaclaw commentedon Jul 8, 2026
Another occurrence from #7416:
d452f3db84ca44c03680055c0e9dcb627d8cd5belinux64-test / Test sourcefeature_governance.py --legacy-wallet864638944927215113Failure mode matches this issue exactly: after
Should see same YES and NO vote count for both triggers on all nodes now, the test reachedShould have 25 votes on all nodesand failed attest/functional/feature_governance.py:313:Scope note: #7416's current PR diff is limited to
src/llmq/net_quorum.cppandtest/functional/p2p_quorum_data.py, so this governance vote-count failure is unrelated to that PR's QDATA vector-bound changes. The later #7416 head4157ce53e6ae2b41ced3d1217bca0a0970d151d2passed the full visible CI matrix, includinglinux64-test / Test source.thepastaclaw commentedon Jul 8, 2026
Another occurrence from #7433:
5f660ae62355b8698bbed4acc4150a48ff242859linux64_ubsan-test / Test sourcefeature_governance.py --legacy-wallet1999716623579542280Failure mode matches this issue: after
Should see same YES and NO vote count for both triggers on all nodes now, the test reachedShould have 25 votes on all nodesand failed attest/functional/feature_governance.py:313:Scope note: #7433 is the Bitcoin Core v0.26 backport batch 3 draft. Its PR diff does not touch
test/functional/feature_governance.py. The onlysrc/net_processing.cppchanges are the bitcoin#27625 transaction relay/mapRelay changes around non-mempool tx relay and most-recent-block transaction lookup; they do not change governance object/vote handling. A local rerun of the failing command on the PR branch passed:thepastaclaw commentedon Jul 18, 2026
New occurrence on #7401 at exact head 45821d0:
This matches the existing intermittent governance vote-propagation/synchronization failure family. The PR branch was left unchanged.
thepastaclaw commentedon Jul 24, 2026
Another occurrence from #7479 at exact head
bc52f0a9c79cc584342142fdf613d961b7df19b6:linux64_ubsan-test / Test sourcefeature_governance.py --descriptors4179883554465678946Should have 25 votes on all nodes,feature_governance.py:313observed 24 votes instead of 25:The descriptor test exhausted all three runner attempts with this same intermittent missing-vote condition, while the legacy-wallet variant passed in the same job.
Scope evidence: #7479's actual merge-base/GitHub PR diff is limited to wallet coin-selection, wallet GUI/RPC/test adaptations, and its wallet transaction benchmark. It does not touch
feature_governance.pyor governance vote propagation. Attempt 2 then passed the full matrix at the identical head, includinglinux64_ubsan-test / Test source: https://github.com/dashpay/dash/actions/runs/30008651352/attempts/2This is another instance of the pre-existing vote-propagation/synchronization flake tracked here. The PR branch was left unchanged.