Fix proposal_votes PK collapsing batch_vote rows - #59
Open
sausagee wants to merge 2 commits into
Open
Conversation
batch_vote / batch_partial_vote emit one VoteEvent per stake pool in the same transaction. The old primary key (transaction_version, proposal_id, voter_address) made the storer's ON CONFLICT DO NOTHING silently drop every pool after the first. Co-authored-by: Young Yang Liauw <sausagee@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bug
proposal_votesis keyed as(transaction_version, proposal_id, voter_address).0x1::aptos_governance::batch_vote/batch_partial_voteloopvote_internaland emit oneVoteEventper stake pool in a single transaction. Those events share voter + proposal and differ only onstake_pool.The storer then does
ON CONFLICT (transaction_version, proposal_id, voter_address) DO NOTHING, so every pool after the first is silently dropped while the stake processor checkpoint still advances.Root cause
The table stores
staking_pool_addressbut never included it in the primary key. That was fine when onlyvoteexisted (one pool per txn). Batch voting (aptos-core #13026) made the 3-column key too narrow.Fix
staking_pool_addressto the Diesel PK, schema, and upsert conflict target.proposal_votes_pkeyto the 4-column key.VoteEvent+ moduleVote) and shows the old 3-column key would collapse while the new key keeps both rows.Tests
cargo test -p processor --lib processors::stake::models::proposal_votes— passRUST_MIN_STACK=67108864 cargo clippy -p processor --lib --tests -- -D warnings— pass