fix(pxe): widen tracked sender tagging ranges with onchain discovery evidence#24655
Draft
vezenovm wants to merge 10 commits into
Draft
fix(pxe): widen tracked sender tagging ranges with onchain discovery evidence#24655vezenovm wants to merge 10 commits into
vezenovm wants to merge 10 commits into
Conversation
vezenovm
added
ci-no-fail-fast
…ial-revert repro Also tightens the storePendingIndexes JSDoc wording.
…n sender sync comments
…evidence (#24663) Stacked on #24655. Found while reviewing #24655. This is the "Window straddle" residual edge flagged in https://gist.github.com/nventuro/0aa690736b1d2865e27197723a814e9d (latent regardless of reverts); the fix takes the gist's suggested "extend an entry monotonically" option. #24655 made discovery skip a differing range for an already tracked (secret, txHash) pair instead of throwing. Before #24655 this same scenario hit the "Conflicting range" throw and permanently wedged the secret, so it was broken either way. Fix: replace `skipExisting` with `mergeExisting`. On a range mismatch, discovery widens the stored entry to the union of both ranges (grow-only, driven by onchain evidence). The partial revert case is unchanged: the discovered sub-range unions to the existing prove-time entry, and the finalized receipt step still resolves it. The prove-time persist path keeps the strict conflict throw. Red-green: - "widens a tracked pending range when discovery evidences further indexes for the same tx" fails on the base branch with lastUsed 10 instead of 11, and passes with the merge. - "assembles a pending range piecewise when a tx straddles the sync window boundary" drives the actual window-advance loop: a tx with tags on both sides of the window boundary gets stored as [83, 83] by window 1 and widened by window 2. It throws "Conflicting range existing [83, 83] vs new [84, 84]" on fairies-v5, under-reports lastUsed as 83 on the base branch, and passes with the merge (including a follow-up sync that finalizes the widened entry cleanly). Store-level tests pin the union semantics: a sub-range keeps the entry, a range beyond it widens it, an untracked tx still stores.
vezenovm
changed the title
storePendingIndexes is strict-only again: no opt can disable the conflicting-range bug detector the prove-time path relies on. Discovery opts into the grow-only union by calling the new mergePendingIndexes, which shares the same transaction body. Also folds the untracked-tx merge store test into the basic insert test as a parameterized case.
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
1 participant
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.
Fixes the sender tag sync conflict from https://gist.github.com/nventuro/0aa690736b1d2865e27197723a814e9d, including the "Window straddle" residual edge.
Discovery could re-derive a different index range for an already tracked (secret, txHash) pair and hit the
Conflicting rangethrow instorePendingIndexes, permanently wedging the secret. Two triggers:Fix: discovery passes
mergeExistingtostorePendingIndexes, which widens the stored entry to the union of both ranges (grow-only, driven by onchain evidence). The finalized receipt step still resolves partial reverts. The only other writer of pending ranges,persistSenderTaggingIndexRangesForTx(records the indexes a tx sent from this PXE used, at prove time), does not pass the flag and still throws on a mismatch: there it indicates a bug, not partial onchain evidence.Red-green (all fail on the base with the
Conflicting rangethrow):Store-level tests pin the union semantics: a sub-range keeps the entry, a range beyond it widens it, an untracked tx still stores.