After a successful feed_qr_info, every rotated quorum on masternode_lists[h] reads Skipped(MissingRotationChainLockSigs) even when those same quorums were validated and stored as Verified in rotated_quorums_per_cycle.
Cause
feed_qr_info runs a late can_verify_previous re-validation block after the current-cycle path has already completed. That block re-validates the entries held on the masternode list without attaching their quarter ChainLock signatures, so validation cannot proceed and each entry is downgraded to Skipped. The authoritative map is unaffected, which is why InstantSend verification still works.
Observed on the qrinfo_2518986 fixture introduced by PR #934: 31 entries stored Verified under the previous cycle hash, while the corresponding entries on masternode_lists[h] all read Skipped.
Why it matters
Two sources of truth disagree about the same quorum. Anything reading verification status off the masternode list rather than rotated_quorums_per_cycle sees rotated quorums as unverified, which is misleading in logs and diagnostics and is a trap for future callers. It also makes the status mirroring in feed_qr_info harder to reason about, since a later block silently overwrites statuses an earlier block established correctly.
Suggested fix
Either attach the per-work-height quarter signatures (quarter_sigs_for_quorum) before the can_verify_previous re-validation, or skip re-validating entries whose status was already established in this same feed. The second is likely smaller and removes redundant BLS work. Worth confirming whether the block is needed at all now that the current-cycle and previous-cycle paths both mirror their statuses onto the masternode lists.
Pre-existing, not introduced by #934.
After a successful
feed_qr_info, every rotated quorum onmasternode_lists[h]readsSkipped(MissingRotationChainLockSigs)even when those same quorums were validated and stored asVerifiedinrotated_quorums_per_cycle.Cause
feed_qr_inforuns a latecan_verify_previousre-validation block after the current-cycle path has already completed. That block re-validates the entries held on the masternode list without attaching their quarter ChainLock signatures, so validation cannot proceed and each entry is downgraded toSkipped. The authoritative map is unaffected, which is why InstantSend verification still works.Observed on the
qrinfo_2518986fixture introduced by PR #934: 31 entries storedVerifiedunder the previous cycle hash, while the corresponding entries onmasternode_lists[h]all readSkipped.Why it matters
Two sources of truth disagree about the same quorum. Anything reading verification status off the masternode list rather than
rotated_quorums_per_cyclesees rotated quorums as unverified, which is misleading in logs and diagnostics and is a trap for future callers. It also makes the status mirroring infeed_qr_infoharder to reason about, since a later block silently overwrites statuses an earlier block established correctly.Suggested fix
Either attach the per-work-height quarter signatures (
quarter_sigs_for_quorum) before thecan_verify_previousre-validation, or skip re-validating entries whose status was already established in this same feed. The second is likely smaller and removes redundant BLS work. Worth confirming whether the block is needed at all now that the current-cycle and previous-cycle paths both mirror their statuses onto the masternode lists.Pre-existing, not introduced by #934.