Fix TokenStore deposit/withdraw owner fallback property-version collision - #68
Open
sausagee wants to merge 3 commits into
Open
Fix TokenStore deposit/withdraw owner fallback property-version collision#68sausagee wants to merge 3 commits into
sausagee wants to merge 3 commits into
Conversation
Token V1 module-event maps used for TokenStore-not-rewritten owner fallback were keyed only by token_data_id. Two property versions of the same named token in one txn overwrote each other, so the current ownership upsert used the wrong owner and the real row was skipped. Key and look up by (token_data_id, property_version). Co-authored-by: Young Yang Liauw <sausagee@users.noreply.github.com>
WriteTableItem/DeleteTableItem data is WriteTableData/DeleteTableData in aptos-protos 1.3.1, not nested write_table_item::Data modules. 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
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
When a Token V1
TokenStoreis not rewritten in a transaction (the usual case after the store is first created), owner fallback for table-item writes/deletes comes from module-event maps:TokenDeposit→tokens_depositedTokenWithdraw→tokens_withdrawnThose maps were keyed only by
token_data_id. Token V1 current-ownership PK is(token_data_id, property_version, owner, storage_id). Two property versions of the same named token in one txn (original vs mutated) collided: last event won, the upsert used the wrong owner, and the real row was never updated. Checkpoints still advanced.This is the sibling that #67 explicitly left out of scope (claim/cancel maps). Distinct from #42 (offer write-path).
Root cause
TokenV1DepositModuleEvents/TokenV1WithdrawModuleEventswereAHashMap<TokenDataIdHash, …>. Inserts and fallback lookups ignoredproperty_version.Fix
Key and look up by
(token_data_id, property_version).Out of scope: same PV + different owners in one txn (module events have no table handle). Same remaining ambiguity as #67.
Tests
deposit_fallback_does_not_reuse_owner_across_property_versionswithdraw_fallback_does_not_reuse_owner_across_property_versionsVerified locally:
cargo test -p processor --lib fallback_does_not_reuse_owner— 2 passedcargo clippy -p processor --all-targets -- -D warnings(plus repo xclippy allows) — cleancargo +nightly fmt -- --checkon the three touched files — cleanNear-misses killed (not in this PR)
0x1::object::ObjectCoreper object per txn.max_gas_octastoring gas units — same as upstream aptos-labs; naming quirk, not Movement-specific corruption.