Update viem to 2.56.3 - #3771
Conversation
Bumps viem from 2.47.10 to 2.56.3 and re-resolves the stale viem lockfile entries so the whole tree shares a single copy. Co-Authored-By: Claude <noreply@anthropic.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 172d40cdfb
ℹ️ 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".
| "ts-node": "^10.9.2", | ||
| "tsx": "^4.21.0", | ||
| "viem": "~2.47.10", | ||
| "viem": "~2.56.3", |
There was a problem hiding this comment.
Regenerate the viem patch after the version bump
On a clean install this selects viem 2.56.3, while the repository still contains only patches/viem+2.47.10.patch. That patch is load-bearing for MegaETH: it adds packed game-data decoding, mega_getWithdrawalProof routing, and ProposalNotValidated handling consumed by src/finalizer/utils/opStack.ts. This leaves deployments dependent on an old-version patch applying cleanly, and postinstall uses patch-package; ..., so a rejected patch can be masked by the following successful command. Regenerate the patch against 2.56.3 so clean deployments cannot silently run the finalizer without those overrides.
AGENTS.md reference: AGENTS.md:L1-L3
Useful? React with 👍 / 👎.
|
I've used my 1 automated round on this PR, so I'm ignoring further automated-reviewer activity. To re-activate me: have a human @-mention |
The MegaETH overrides lived in patches/viem+2.47.10.patch, which does not apply to 2.56.3. patch-package exits 0 on a failed patch unless --error-on-fail is passed, and postinstall chained with `;`, so the failure was silent in both local and CI installs: a clean install produced an unpatched viem and the finalizer lost its MegaETH overrides. Regenerating alone is not sufficient. 2.56.3 rewrote getGames to read l2SequenceNumber() from each dispute game through an allowFailure: false multicall, dropping extraData decoding entirely, so the decodeGameExtraData hook no longer had a call site. MegaETH's games (gameType 1337) revert on l2SequenceNumber(), which fails the multicall for every game and breaks getWithdrawalStatus and getL2Output — both called from opStack.ts. The new patch covers the same 11 files. Seven hunks carry over unchanged; buildProveWithdrawal is rebased onto the new super-roots block; getGames now routes chains exposing a custom decoder around the multicall and decodes extraData locally, leaving every other chain on the upstream path. Verified against live mainnet: stock 2.56.3 getGames throws "The contract function l2SequenceNumber reverted", the patched build returns games with l2BlockNumber 26085600, matching l2BlockNumber() on game 7415 and the packed extraData decode. isSuperGameType(1337) is false, so the super-roots branch stays unused. Clean reinstall applies the patch; typecheck, lint, build and the finalizer tests pass. Co-Authored-By: Claude <noreply@anthropic.com>
|
Codex is right, and the impact is worse than flagged. Confirmed and fixed in The masking is total, not partial. Regenerating alone would not have fixed it. 2.56.3 rewrote
Live against mainnet, patched vs stock:
Changed
Verified: clean reinstall applies the patch; typecheck, lint, build and the finalizer tests (9/9) pass; live Not verified: the prove/finalize path past |
Bumps viem from 2.47.10 to 2.56.3.
Also re-resolves the stale viem lockfile entries. On master the tree carried two viem copies (2.47.10 hoisted, 2.48.4 nested under
@risk-labs/serverless-orchestration); bumping onlypackage.jsonwould have made that three, since yarn keeps the published sdk's locked^2.47.10at 2.47.10. Dropping the stale entries lets all three ranges converge, so the tree now has a single copy. That also removes a latent trap: the sdk'sisViemErroris aninstanceof BaseErrorcheck, which silently returns false for errors raised by a different viem copy. It has no callers today, but it would have started lying the moment it got one.Two behaviour changes in this range are worth knowing about:
http()cap RPC response bodies at 10 MiB by default, throwing a newResponseBodyTooLargeError. This is absent from the changelog.EventListeneris the only place viem does the RPC here, andwatchEventresponses are small, so no expected impact — but it's a live constraint on any future wideeth_getLogsthrough a viem transport. Opt out withhttp(url, { maxResponseBodySize: false }).estimateFeesPerGasbase fee multiplier fromMath.ceiltoMath.round. Sub-wei at our multipliers, and gas pricing goes through the sdk's oracle rather than this path.Typecheck, build and lint pass. Test suite: 1193 passing, 2 failing — both failures reproduce identically on master with viem 2.47.10, so neither is from this change:
Dataworker: Load bundle data > Filters expired depositscompares a wall-clockfillDeadline(getCurrentTime() + 14400) against a hardhat block timestamp, so it breaks once block time drifts past wall-clock in a full-suite run. Passes in isolation on both branches. Happy to file this separately.finalizeCCTPV1Messagesneedssolana-test-validator, which isn't installed in my environment.