Skip to content

Update viem to 2.56.3 - #3771

Open
droplet-rl wants to merge 2 commits into
masterfrom
droplet/T90K0AL22-C0BHMM63D9Q-1788880660-858259
Open

Update viem to 2.56.3#3771
droplet-rl wants to merge 2 commits into
masterfrom
droplet/T90K0AL22-C0BHMM63D9Q-1788880660-858259

Conversation

@droplet-rl

Copy link
Copy Markdown
Contributor

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 only package.json would have made that three, since yarn keeps the published sdk's locked ^2.47.10 at 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's isViemError is an instanceof BaseError check, 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:

  • 2.54.0 made http() cap RPC response bodies at 10 MiB by default, throwing a new ResponseBodyTooLargeError. This is absent from the changelog. EventListener is the only place viem does the RPC here, and watchEvent responses are small, so no expected impact — but it's a live constraint on any future wide eth_getLogs through a viem transport. Opt out with http(url, { maxResponseBodySize: false }).
  • 2.55.10 changed the estimateFeesPerGas base fee multiplier from Math.ceil to Math.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 deposits compares a wall-clock fillDeadline (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.
  • finalizeCCTPV1Messages needs solana-test-validator, which isn't installed in my environment.

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>
@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Sep 8, 2026

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review Completed 2026-09-08T16:12:57.424432Z 172d40c PR opened
ℹ️ 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" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

@socket-security

socket-security Bot commented Sep 8, 2026

Copy link
Copy Markdown

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff Package Supply Chain
Security
Vulnerability Quality Maintenance License
Updatedviem@​2.47.10 ⏵ 2.56.39710010098 +1100

View full report

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 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".

Comment thread package.json
"ts-node": "^10.9.2",
"tsx": "^4.21.0",
"viem": "~2.47.10",
"viem": "~2.56.3",

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge 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 👍 / 👎.

@droplet-rl

Copy link
Copy Markdown
Contributor Author

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 @droplet-rl in a comment (resets the budget), or assign me to the PR (raises the budget to 3 rounds).

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>
@droplet-rl

Copy link
Copy Markdown
Contributor Author

Codex is right, and the impact is worse than flagged. Confirmed and fixed in adaa04dd.

The masking is total, not partial. patch-package exits 0 on a failed patch unless --error-on-fail is passed — so the ; in postinstall wasn't the only thing hiding it, the exit code was 0 regardless. A clean install of this branch silently produced an unpatched viem; I reproduced exactly that before noticing.

Regenerating alone would not have fixed it. 2.56.3 rewrote getGames: it now reads l2SequenceNumber() from each dispute game via an allowFailure: false multicall and no longer decodes extraData at all, so the patch's decodeGameExtraData hook had no call site left. MegaETH's games revert on that method:

  • DisputeGameFactory 0x8546…D563, respectedGameType = 1337, game 7415 → proxy 0xece4…d79d
  • l2SequenceNumber() → reverts
  • l2BlockNumber() → 26085600, matching the packed 24-byte extraData decode (0x00000000018e08e0)

Live against mainnet, patched vs stock:

PATCHED (custom decoder):                  OK -> 3 games, latest l2BlockNumber=26085600
STOCK 2.56.3 (l2SequenceNumber multicall): THREW -> The contract function "l2SequenceNumber" reverted.

getWithdrawalStatusgetGamegetGames and getL2OutputgetGamegetGames, both called from opStack.ts, so MegaETH finalization would have broken at runtime rather than degrading quietly.

Changed

  • patches/viem+2.47.10.patchpatches/viem+2.56.3.patch, same 11 files. Seven hunks carry over unchanged; buildProveWithdrawal is rebased onto the new super-roots block; getGames routes chains exposing a custom decoder around the multicall and decodes locally, leaving every other chain on the upstream path.
  • postinstall: patch-package --error-on-fail && npm run update-addresses.

isSuperGameType(1337) is false, so the new super-roots branch stays unused.

Verified: clean reinstall applies the patch; typecheck, lint, build and the finalizer tests (9/9) pass; live getGames as above.

Not verified: the prove/finalize path past getGames. The mega_getWithdrawalProof routing in buildProveWithdrawal and the ProposalNotValidated handling need a real pending MegaETH withdrawal to exercise — those hunks carried over textually and typecheck, but someone with MegaETH context should confirm they're still semantically right against 2.56.3. The --error-on-fail flip may also surface latent patch failures in CI that were previously swallowed. Happy to take either further if someone assigns me the PR.

@droplet-rl

Copy link
Copy Markdown
Contributor Author

🔎 View trace

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant