🐛 fix(ci): pin zevm checkout and realign lockfile so frozen-lockfile passes - #2083
Conversation
…passes CI has been failing at the Setup step on every PR, including dependabot PRs that only bump an action version. The failure is ERR_PNPM_OUTDATED_LOCKFILE, which aborts install before any suite runs — so Parity, WASM and test failures downstream were all secondary, not real signal. Cause: pnpm-workspace.yaml includes ../zevm/npm/zevm as a workspace member, and the setup action cloned evmts/zevm at --depth 1 (whatever main happened to be). zevm commit e80b7ff bumped typescript ^5.9.0 -> ^6.0.3 and @types/node ^22.15.0 -> ^25.9.1, which instantly invalidated this repo's lockfile. Any dependency change in a different repository could break CI here at any time. - Pin the zevm checkout to e891cf6 and document that bumping it requires regenerating pnpm-lock.yaml in the same commit. - Update the ../zevm/npm/zevm lockfile importer to the pinned specifiers. typescript@6.0.3 and @types/node@25.9.1 were already resolved in the lockfile, so this is a 4-line specifier realignment rather than a re-resolution (a full re-resolve would silently bump vite 7->8, react 18->19 and viem 2.35->2.49 across the tree). Verified with CI's exact pnpm: `pnpm@10.33.4 install --frozen-lockfile` now completes instead of aborting.
|
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
|
Claude encountered an error —— View job I'll analyze this and get back to you. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughCI workflows now pin zevm, build ChangesCI workflow updates
Test expectation updates
Estimated code review effort: 3 (Moderate) | ~20 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Claude encountered an error —— View job I'll analyze this and get back to you. |
The conformance harness imports built output (test/conformance-utils/ run-fixture-suite.mjs loads @tevm/block/dist/index.js), but the parity workflow invoked the suites straight after setup with no build step, so every job failed with ERR_MODULE_NOT_FOUND. This was previously masked: install aborted earlier in setup with ERR_PNPM_OUTDATED_LOCKFILE, so the suites never got far enough to reveal the missing build.
|
Claude encountered an error —— View job I'll analyze this and get back to you. |
…ename release.yml, prerelease.yml, snapshot.yml and jsr-publish.yml all gate on `github.repository == 'evmts/tevm-monorepo'`. Renaming the repo to evmts/tevm made every one of those conditions false, silently disabling releases, prereleases, snapshots and JSR publishing — the jobs would report success while skipping all of their work.
|
Claude encountered an error —— View job I'll analyze this and get back to you. |
…hange Commit 4196792 ("resolve 23 confirmed correctness bugs") deliberately changed packages/node/src/GENESIS_STATE.js — raising INITIAL_BALANCE from parseEther('1000') to parseEther('10000') and adding the Multicall3 predeploy at 0xcA11bde05977b3631167028862bE2a173976CA11 — but the affected snapshots and one hardcoded assertion were never updated. Nobody saw the fallout because CI aborted during install (ERR_PNPM_OUTDATED_LOCKFILE) long before the test step ran, so main has been carrying ~11 failing tests invisibly. The regenerated diff contains only the two intended genesis changes: balance 0x3635c9adc5dea00000 -> 0x21e19e0c9bab2400000 (1000 -> 10000 ETH) and the added Multicall3 account. No successful call became an error and no behavioral assertion changed meaning, so this is snapshot drift from an intentional source change rather than a regression. - 16 snapshots regenerated in packages/actions (70 files / 337 tests pass) - tevmGetAccount.spec.ts asserted parseEther('1000') directly; updated to match
|
Claude encountered an error —— View job I'll analyze this and get back to you. |
…l3 predeploy The test asserted all three aggregate3 calls FAIL with an error mentioning 'aggregate3' — it encoded the old behavior where Multicall3 was not deployed in genesis. Commit 4196792 added the Multicall3 predeploy at 0xcA11bde05977b3631167028862bE2a173976CA11, so multicall now works and returns 420n for each call. This is an error-becoming-success diff, i.e. the predeploy doing its job, so the expectation is updated to assert the working behavior rather than the old gap.
|
Claude encountered an error —— View job I'll analyze this and get back to you. |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
bundler-packages/requirejs/src/index.spec.ts (1)
5-7: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winAdd explicit return types to the test callbacks.
These TypeScript callbacks currently rely on inference. Add
(): voidto satisfy the repository rule requiring explicit function return types.As per coding guidelines, TypeScript functions must always explicitly type their return types.
Proposed change
- it('should export requirejsPluginTevm', () => { + it('should export requirejsPluginTevm', (): void => { ... - it('should export requirejsFileAccessObject', () => { + it('should export requirejsFileAccessObject', (): void => {Also applies to: 10-12
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@bundler-packages/requirejs/src/index.spec.ts` around lines 5 - 7, Update both test callbacks in the requirejsPluginTevm tests to explicitly declare a void return type, including the callback beginning with “should export requirejsPluginTevm.”Source: Coding guidelines
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/actions/setup/action.yml:
- Around line 45-47: Update the Zevm setup block to always validate and enforce
ZEVM_REF, regardless of whether ../zevm/npm/zevm already exists. For an existing
workspace, verify it is the expected repository, fetch the pinned commit when
unavailable, and run the detached git checkout on every invocation; retain
cloning only for missing workspaces.
---
Nitpick comments:
In `@bundler-packages/requirejs/src/index.spec.ts`:
- Around line 5-7: Update both test callbacks in the requirejsPluginTevm tests
to explicitly declare a void return type, including the callback beginning with
“should export requirejsPluginTevm.”
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 986fe230-fc06-455c-b4c9-7f871499763f
⛔ Files ignored due to path filters (12)
packages/actions/src/DumpState/__snapshots__/dumpStateProcedure.spec.ts.snapis excluded by!**/*.snappackages/actions/src/anvil/__snapshots__/anvilDumpStateProcedure.spec.ts.snapis excluded by!**/*.snappackages/actions/src/debug/__snapshots__/debugTraceBlockByHashProcedure.spec.ts.snapis excluded by!**/*.snappackages/actions/src/debug/__snapshots__/debugTraceBlockByNumberProcedure.spec.ts.snapis excluded by!**/*.snappackages/actions/src/debug/__snapshots__/debugTraceCallProcedure.spec.ts.snapis excluded by!**/*.snappackages/actions/src/debug/__snapshots__/debugTraceStateProcedure.spec.ts.snapis excluded by!**/*.snappackages/actions/src/debug/__snapshots__/debugTraceTransactionProcedure.spec.ts.snapis excluded by!**/*.snappackages/actions/src/debug/__snapshots__/traceCallHandler.spec.ts.snapis excluded by!**/*.snappackages/actions/src/internal/__snapshots__/runCallWithPrestateTrace.spec.ts.snapis excluded by!**/*.snappnpm-lock.yamlis excluded by!**/pnpm-lock.yamltest/memory-client/src/__snapshots__/tevmDumpState.spec.ts.snapis excluded by!**/*.snaptest/memory-client/src/__snapshots__/tevmGetAccount.spec.ts.snapis excluded by!**/*.snap
📒 Files selected for processing (9)
.github/actions/setup/action.yml.github/workflows/jsr-publish.yml.github/workflows/parity-suites.yml.github/workflows/prerelease.yml.github/workflows/release.yml.github/workflows/snapshot.ymlbundler-packages/requirejs/src/index.spec.tspackages/memory-client/src/test/viem/multicall.spec.tstest/memory-client/src/tevmGetAccount.spec.ts
| if [ ! -d ../zevm/npm/zevm ]; then | ||
| git clone --depth 1 https://github.com/evmts/zevm.git ../zevm | ||
| git clone --filter=blob:none https://github.com/evmts/zevm.git ../zevm | ||
| git -C ../zevm checkout --detach "$ZEVM_REF" |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Enforce the pinned Zevm revision even when the workspace already exists.
If ../zevm/npm/zevm is present from a reused or cached workspace, this skips both checkout and SHA validation, allowing a stale revision to recreate ERR_PNPM_OUTDATED_LOCKFILE. Validate the repository, fetch the pinned commit if needed, and run the detached checkout on every invocation.
Proposed fix
- if [ ! -d ../zevm/npm/zevm ]; then
+ if [ ! -d ../zevm/.git ]; then
git clone --filter=blob:none https://github.com/evmts/zevm.git ../zevm
- git -C ../zevm checkout --detach "$ZEVM_REF"
fi
+ if ! git -C ../zevm cat-file -e "${ZEVM_REF}^{commit}" 2>/dev/null; then
+ git -C ../zevm fetch --filter=blob:none https://github.com/evmts/zevm.git "$ZEVM_REF"
+ fi
+ git -C ../zevm checkout --detach "$ZEVM_REF"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| if [ ! -d ../zevm/npm/zevm ]; then | |
| git clone --depth 1 https://github.com/evmts/zevm.git ../zevm | |
| git clone --filter=blob:none https://github.com/evmts/zevm.git ../zevm | |
| git -C ../zevm checkout --detach "$ZEVM_REF" | |
| if [ ! -d ../zevm/.git ]; then | |
| git clone --filter=blob:none https://github.com/evmts/zevm.git ../zevm | |
| fi | |
| if ! git -C ../zevm cat-file -e "${ZEVM_REF}^{commit}" 2>/dev/null; then | |
| git -C ../zevm fetch --filter=blob:none https://github.com/evmts/zevm.git "$ZEVM_REF" | |
| fi | |
| git -C ../zevm checkout --detach "$ZEVM_REF" |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/actions/setup/action.yml around lines 45 - 47, Update the Zevm setup
block to always validate and enforce ZEVM_REF, regardless of whether
../zevm/npm/zevm already exists. For an existing workspace, verify it is the
expected repository, fetch the pinned commit when unavailable, and run the
detached git checkout on every invocation; retain cloning only for missing
workspaces.
The two batch-option tests asserted exact equality against the bare message, but InvalidRequestError extends BaseError, which appends the standard docs reference — so the real message is 'Empty batch requests are invalid' followed by a blank line and a docs link. The implementation is correct (and the appended diagnostics are the repo's error convention); the assertions were simply too strict. Switched to toContain, which is what the neighbouring jsonrpc assertion in the same file already does.
|
Claude encountered an error —— View job I'll analyze this and get back to you. |
22 vitest configs set coverage `thresholds: { autoUpdate: true }`, so
`pnpm test:coverage` rewrites those tracked config files in place. The rewritten
indentation is not what biome would print, so the Lint step — which ran after
Tests — failed on the pipeline's own mutations rather than on anything the PR
changed. The failing file was a vitest.config.ts whose thresholds had just been
rewritten by the preceding step.
Linting first also fails faster and does not depend on test results.
This was invisible until now: CI aborted during install, so the Tests step never
ran and never mutated anything.
|
Claude encountered an error —— View job I'll analyze this and get back to you. |
…upport (#2084) ## Motivation `@tevm/server` served HTTP only — `createHttpHandler` and `createServer`, no WebSocket anywhere. That gap is the reason viem's test suite must keep Anvil around for its `webSocket()` transport suites: Anvil serves ws and http on the same port, and Tevm could not. The hard half was already built — `packages/actions/src/eth/ethSubscribeHandler.js` implements `eth_subscribe`. What was missing was a transport to expose it. ## What this adds - `createWebSocketServer` — JSON-RPC over WebSocket, served on the same port as HTTP. - `eth_subscribe` / `eth_unsubscribe` wired so subscriptions actually push notifications to connected clients. - Connection lifecycle handling and cleanup so sockets don't leak. - Exported through the package barrels and the top-level `tevm` package. ## Testing `packages/server/src/createWebSocketServer.spec.ts` — **5/5 passing**, verified locally: ``` Test Files 1 passed (1) Tests 5 passed (5) ``` No mocking, per the repo's testing conventions. ## Note on CI This branch is based on `main`, which is currently red for an unrelated reason (`ERR_PNPM_OUTDATED_LOCKFILE` from the unpinned zevm workspace checkout). #2083 fixes that; once it lands this needs a rebase for a clean signal. 🤖 Generated with Smithers multi-agent orchestration
|
Reviewed the merged CI repair, including the pinned Zevm commit, its package manifest versus the lockfile importer, build-before-parity ordering, repository-name guards, and the snapshot/test realignment caused by the pinned Zevm behavior. The pinned SHA exists and its TypeScript 6 manifest matches the committed lockfile. I found no additional correctness defect in this PR. |
## The failure Every package fails to publish with `E422`: ``` npm error 422 Unprocessable Entity - PUT https://registry.npmjs.org/tevm Error verifying sigstore provenance bundle: Failed to validate repository information: package.json: "repository.url" is "git+https://github.com/evmts/tevm-monorepo.git", expected to match "https://github.com/evmts/tevm" from provenance ``` ## Cause The repo was renamed `evmts/tevm-monorepo` → `evmts/tevm`. GitHub redirects the old URL, so nothing looked broken — but the OIDC **provenance statement carries the current repository name**, and npm validates it against `repository.url` in package.json. All 85 package.json files still declared the old name, so the package signed successfully and then failed verification at the registry. This is the same class of rename fallout as the four release workflows that were gated on `github.repository == 'evmts/tevm-monorepo'` (fixed in #2083). ## Change All 85 `package.json` repository URLs updated. JSON validity verified across every file. Publishing is blocked until this merges. 🤖 Generated with Smithers multi-agent orchestration
The problem
CI has been red at the Setup step on every PR — including dependabot PR #2074, which only bumps a GitHub Action version. Because install aborts, every downstream check (Parity RPC, Parity Conformance, Hive Smoke, WASM Size, tests) reports failure without having run. None of those were real signal.
Root cause
pnpm-workspace.yamlincludes../zevm/npm/zevmas a workspace member, and.github/actions/setupclonedevmts/zevmwith--depth 1— i.e. whatevermainhappened to be at that moment. zevm commite80b7ffbumpedtypescriptand@types/node, which instantly invalidated this repo's lockfile.The structural problem is that a dependency change in a different repository could break this repo's CI at any time, with no commit here to explain it.
The fix
e891cf6, with a comment stating that bumping it requires regeneratingpnpm-lock.yamlin the same commit.../zevm/npm/zevmlockfile importer to the pinned specifiers.typescript@6.0.3and@types/node@25.9.1were already resolved elsewhere in the lockfile, so this is a 4-line specifier realignment, not a re-resolution. That was deliberate: a full--lockfile-onlyre-resolve silently bumped vite 7→8, react 18→19 and viem 2.35→2.49 across the tree, which is a dependency upgrade masquerading as a CI fix and belongs in its own reviewed PR.Verification
Run with CI's exact pnpm version:
Previously this aborted with
ERR_PNPM_OUTDATED_LOCKFILE.🤖 Generated with Smithers multi-agent orchestration
Summary by CodeRabbit