feat: use forked ponder version#2345
Conversation
🦋 Changeset detectedLatest commit: afde99d The changes in this PR will be included in the next version bump. This PR includes changesets to release 23 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Warning Review limit reached
Next review available in: 49 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThis PR switches ENSIndexer's ponder dependency to NameHash's published fork ( ChangesPonder Fork Migration
Integration Test Environment Reliability
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant Start as start.ts (main)
participant Lifecycle as bringUp()
participant Compose as DockerComposeEnvironment
participant Docker as Docker CLI
Start->>Lifecycle: bringUp()
Lifecycle->>Compose: up() with wait-for-log-line strategy
Compose-->>Lifecycle: efp-devnet started
Lifecycle->>Docker: containerHealth(efp-devnet-orchestrator)
loop until healthy or attempts exhausted
Docker-->>Lifecycle: health status
alt not healthy
Lifecycle->>Docker: docker restart
end
end
Docker-->>Lifecycle: healthy
Lifecycle-->>Start: bringUp complete
Start->>Start: setInterval keep-alive
Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 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 |
Greptile SummarySwitches
Confidence Score: 5/5Safe to merge — the changes are a well-scoped dependency swap and targeted integration test hardening with no impact on production code paths. The ponder fork switch is mechanically straightforward (catalog alias + lockfile update + patch removal) and the transitive dependency tree is identical. The waitForContainerHealthyWithRestart logic is correct: each attempt gets a fresh 20 s budget after restart, the last attempt does not spuriously restart, and containerHealth() now fails loudly instead of silently returning an empty string. The only non-blocking observation is that execaSync is used for docker restart, blocking the event loop for the container stop cycle, which is an acceptable trade-off in test infrastructure. No files require special attention; lifecycle.ts is the most complex change but the logic has been verified to be correct. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[DockerComposeEnvironment.up] --> B[Wait.forLogMessage\n/Starting EFP devnet/]
B --> C{180s startup\ntimeout exceeded?}
C -- Yes --> FAIL1[Throw startup timeout]
C -- No --> D[waitForContainerHealthyWithRestart\n10 attempts x 20s each]
D --> E{docker inspect\nhealthy?}
E -- Yes --> OK[Return — EFP Devnet ready]
E -- No, exit!=0 --> FAIL2[Throw: container missing\nor docker error]
E -- No, still starting/unhealthy --> F{perAttemptMs\n20s elapsed?}
F -- No --> E
F -- Yes, attempt < 10 --> G[execaSync docker restart\nblocks ~10-30s]
G --> H{restart exit\ncode != 0?}
H -- Yes --> FAIL3[Throw: restart failed]
H -- No --> D
F -- Yes, attempt = 10 --> FAIL4[Throw: not healthy\nafter 10 attempts]
%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
A[DockerComposeEnvironment.up] --> B[Wait.forLogMessage\n/Starting EFP devnet/]
B --> C{180s startup\ntimeout exceeded?}
C -- Yes --> FAIL1[Throw startup timeout]
C -- No --> D[waitForContainerHealthyWithRestart\n10 attempts x 20s each]
D --> E{docker inspect\nhealthy?}
E -- Yes --> OK[Return — EFP Devnet ready]
E -- No, exit!=0 --> FAIL2[Throw: container missing\nor docker error]
E -- No, still starting/unhealthy --> F{perAttemptMs\n20s elapsed?}
F -- No --> E
F -- Yes, attempt < 10 --> G[execaSync docker restart\nblocks ~10-30s]
G --> H{restart exit\ncode != 0?}
H -- Yes --> FAIL3[Throw: restart failed]
H -- No --> D
F -- Yes, attempt = 10 --> FAIL4[Throw: not healthy\nafter 10 attempts]
Reviews (2): Last reviewed commit: "add error checks" | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
Pull request overview
This PR switches the monorepo’s ponder catalog dependency to NameHash’s published fork (@ensnode/ponder via npm aliasing) to improve crash-recovery behavior, and hardens the integration test environment’s devnet startup so it doesn’t exit early and can recover from a known efp-devnet healthcheck stall.
Changes:
- Replace upstream
ponder@0.16.6with the aliased forkponder: npm:@ensnode/ponder@0.16.7and update lockfile/overrides accordingly. - Remove the local pnpm patch previously applied to upstream
ponder@0.16.6. - Improve
integration-test-envreliability: keep the process alive instart.ts, and add “restart-and-retry” health handling forefp-devnetinlifecycle.ts.
Reviewed changes
Copilot reviewed 6 out of 7 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| pnpm-workspace.yaml | Updates the pnpm catalog entry to alias ponder to npm:@ensnode/ponder@0.16.7. |
| pnpm-lock.yaml | Refreshes lockfile state for the forked Ponder package and updated override selectors. |
| patches/ponder@0.16.6.patch | Removes the no-longer-used patch for the old upstream Ponder version. |
| package.json | Updates pnpm overrides and removes the patchedDependencies entry for ponder@0.16.6. |
| packages/integration-test-env/src/start.ts | Ensures the manual start command stays alive even when no long-lived child process is spawned. |
| packages/integration-test-env/src/lifecycle.ts | Adds container health polling with restart-and-retry for efp-devnet and adjusts testcontainers wait strategy accordingly. |
| .changeset/ensindexer-ponder-fork.md | Adds a changeset noting the move to the NameHash Ponder fork for ensindexer. |
Files not reviewed (1)
- pnpm-lock.yaml: Generated file
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Lite PR
Tip: Review docs on the ENSNode PR process
Summary
integration-test-envWhy
Pre-Review Checklist (Blocking)