fix(taiko-client-rs): use anchor tx calldata fallback for early mainnet proposals - #21530
fix(taiko-client-rs): use anchor tx calldata fallback for early mainnet proposals#21530ggonzalez94 wants to merge 1 commit into
Conversation
…et proposals The first Shasta proposals (1-7) on Taiko mainnet had reverted anchor transactions, causing getBlockState() to return stale anchor data. For those proposals the Rust driver now parses the anchor block number from the parent block's anchorV4 calldata instead. This is the Rust equivalent of the Go driver fix in PR #21529. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
@codex please review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7cb3b38747
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| let use_calldata_fallback = self.chain_id == TAIKO_MAINNET_CHAIN_ID | ||
| && proposal_id >= 1 | ||
| && proposal_id <= MAINNET_ANCHOR_CHECK_SKIP_PROPOSAL_OFFSET; |
There was a problem hiding this comment.
Extend fallback window to include proposal 8
The fallback guard is off by one relative to how initialize_parent_state is used: this method resolves the parent block’s anchor (load_parent_block uses proposal_id - 1), so if proposals 1–7 have reverted anchorV4 txs, proposal 8 still depends on a reverted parent and must also use calldata fallback. With the current proposal_id <= 7 condition, proposal 8 reverts to getBlockState() and can read stale anchor state again, which can break derivation/canonical matching during early mainnet catch-up.
Useful? React with 👍 / 👎.
|
Closed by #21532 |
#21529 for taiko-client-rs