feat(ensindexer): re-derive Resolver.extended on EIP-1967 proxy upgrade (.box)#2280
feat(ensindexer): re-derive Resolver.extended on EIP-1967 proxy upgrade (.box)#2280shrugs wants to merge 8 commits into
Conversation
…rade Resolver `isExtended` (ENSIP-10 IExtendedResolver support) was classified once at first visibility. Proxy Resolvers that activate IExtendedResolver via a post-assignment upgrade (e.g. the 3DNS Resolver behind `.box`) were stuck `false` forever, silently breaking wildcard resolution. The Protocol Acceleration plugin now watches the 3DNS Resolver's EIP-1967 `Upgraded` events and re-runs the supportsInterface probe against the new implementation, updating the stored row. Scoped to the `.box` case. Fixes #2275.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
3 Skipped Deployments
|
🦋 Changeset detectedLatest commit: 212e450 The changes in this PR will be included in the next version bump. This PR includes changesets to release 24 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 |
|
Warning Review limit reached
More reviews will be available in 41 minutes and 28 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (4)
📝 WalkthroughWalkthroughThe PR adds on-chain event detection for proxy resolver upgrades (EIP-1967) and re-derives ENSIP-10 IExtendedResolver support when the implementation changes, fixing cases where proxy resolvers remained incorrectly marked as non-extended after upgrades. ChangesProxy Resolver Upgrade Handler
Sequence DiagramsequenceDiagram
participant Chain as On-Chain Proxy
participant Handler as UpgradableProxyResolver Handler
participant UpdateLogic as updateResolverInterfaces
participant DB as Resolver Database
Chain->>Handler: emit Upgraded(implementation)
Handler->>UpdateLogic: handleResolverImplementationChange
UpdateLogic->>UpdateLogic: isExtendedResolver check
UpdateLogic->>DB: update resolver.extended flag
DB-->>UpdateLogic: confirmation
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related issues
Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 SummaryThis PR fixes a stale
Confidence Score: 5/5Safe to merge; the change is narrowly scoped to one known proxy address, all logic paths are correctly guarded, and the RPC probe is always safe to retry via the Upgraded event. The refactored upsertResolver two-step is safe because isExtendedResolver catches every revert and returns false rather than throwing, so the insert is never left without a subsequent update. The handleResolverImplementationChange guard correctly no-ops for unknown addresses. The optional DotBoxL1Resolver spread mirrors existing codebase patterns and degrades gracefully to an empty chain config when the contract is absent. No callers of upsertResolver consumed its return value, so the void return is non-breaking. No files require special attention. Important Files Changed
Reviews (5): Last reviewed commit: "refactor: spell UpgradeableProxyResolver..." | 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 fixes stale Resolver.extended (ENSIP-10 IExtendedResolver support) for the .box TLD resolver by re-deriving the indexed isExtended flag when a known EIP-1967 proxy resolver emits an Upgraded event, rather than freezing the value at first visibility.
Changes:
- Add a minimal EIP-1967
Upgraded(address)ABI and expose it via@ensnode/datasources. - Add the
.boxresolver proxy address to the ENSRoot mainnet datasource and register a dedicated Protocol Acceleration contract to listen forUpgraded. - Update resolver DB helpers to support re-deriving supported-interface flags for already-indexed resolvers on proxy upgrades.
Reviewed changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| packages/datasources/src/mainnet.ts | Adds DotBoxL1Resolver contract metadata (address + startBlock) for mainnet ENSRoot. |
| packages/datasources/src/index.ts | Re-exports the new UpgradeableProxyABI from datasources. |
| packages/datasources/src/abis/shared/UpgradeableProxy.ts | Introduces minimal EIP-1967 proxy ABI for Upgraded event decoding. |
| apps/ensindexer/src/plugins/protocol-acceleration/plugin.ts | Registers an Upgraded event source (scoped to .box proxy) for interface re-derivation. |
| apps/ensindexer/src/plugins/protocol-acceleration/handlers/UpgradableProxyResolver.ts | Adds handler that triggers resolver interface re-derivation on Upgraded. |
| apps/ensindexer/src/plugins/protocol-acceleration/event-handlers.ts | Wires the new UpgradableProxyResolver handler into protocol-acceleration. |
| apps/ensindexer/src/lib/protocol-acceleration/resolver-db-helpers.ts | Refactors resolver upsert + adds handleResolverImplementationChange to update isExtended for indexed resolvers. |
| .changeset/reclassify-extended-on-proxy-upgrade.md | Adds a patch changeset describing the behavior fix. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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 `@apps/ensindexer/src/lib/protocol-acceleration/resolver-db-helpers.ts`:
- Around line 36-51: The callers in Resolver.ts and Registry.ts expect
upsertResolver to return the resolver row (they access resolver.coinTypes,
resolver.texts, resolver.addrId) but upsertResolver currently returns void;
restore the original behavior by returning the resolver entity: after computing
id and checking/inserting, fetch or construct the inserted/updated resolver
record and return it (use context.ensDb.find or the insert result) while still
calling updateResolverInterfaces(context, resolver); ensure the returned shape
matches the callers' expectations (fields like coinTypes, texts, addrId) and
update the function's Promise return type accordingly.
In `@apps/ensindexer/src/plugins/protocol-acceleration/plugin.ts`:
- Around line 105-119: The namespace key uses the nonstandard spelling
"UpgradableProxyResolver" while the ABI and standards use
"UpgradeableProxyResolver"; update all references to standardize the name:
rename the namespaceContract entry from "UpgradableProxyResolver" to
"UpgradeableProxyResolver", update any handler/file names and exports that
reference that symbol, and adjust any imports/usages (e.g., the handler file and
any call sites referencing UpgradableProxyResolver, plus the UpgradeableProxyABI
and DotBoxL1Resolver references) so the project consistently uses
"UpgradeableProxyResolver" across the codebase.
🪄 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: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: e7e7d31c-59bc-4639-ba4e-3212bf01e23c
📒 Files selected for processing (8)
.changeset/reclassify-extended-on-proxy-upgrade.mdapps/ensindexer/src/lib/protocol-acceleration/resolver-db-helpers.tsapps/ensindexer/src/plugins/protocol-acceleration/event-handlers.tsapps/ensindexer/src/plugins/protocol-acceleration/handlers/UpgradableProxyResolver.tsapps/ensindexer/src/plugins/protocol-acceleration/plugin.tspackages/datasources/src/abis/shared/UpgradeableProxy.tspackages/datasources/src/index.tspackages/datasources/src/mainnet.ts
|
@greptile review |
|
@greptile review |
Summary
Fixes #2275. ENSIndexer classifies a Resolver's
IExtendedResolver(ENSIP-10) support once, at the block the resolver is first seen, via an eip-165supportsInterfaceprobe. For proxy resolvers that activateIExtendedResolverafter they're assigned (deploy-then-upgrade), that snapshot is computed against the pre-upgrade implementation and gets stuckfalseforever.A stale
falsesilently breaks ENSIP-10 wildcard resolution: affected names don't virtualize intoUnindexedDomainandDomain.resolvereturnsnull. The concrete case is the.boxTLD (3DNS), whose resolver0xf97aac6c8dbaebcb54ff166d79706e3af7a813c8is an EIP-1967 proxy:supportsInterface(0x9061b923)box's resolver (impl0xb4cd…959b)Upgraded→ impl0xee65…4546First-visibility probed at 19128555 (pre-upgrade → revert) → cached
is_extended = false, never re-checked →mystery.boxreturnednullinstead of0x130EF…7562.What this does
Keeps
extendedindexed (nosupportsInterfaceRPC at query / acceleration time) and adds the agreed direction from the issue: classify on first visibility + re-derive on a known proxy upgrade pattern.UpgradeableProxyABI (@ensnode/datasources) — just EIP-1967Upgraded(address indexed implementation).DotBoxL1Resolvercontract in the Mainnet ENSRoot datasource (the 3DNS proxy address).UpgradableProxyResolvercontract over that address and, on eachUpgraded, re-runs the eip-165 probe against the new implementation and updates the row (handleResolverImplementationChange). The re-derivation no-ops for any address that isn't already an indexed Resolver, so it never creates junk rows.Why scoped to a single address (not a chain-wide
Upgradedfilter)An address-less
Upgradedtopic filter would auto-cover every proxy resolver but means fetching/decoding ~5–6MUpgradedlogs per full reindex (sampled estimate: ~1M mainnet, ~3M Base, ~0.5M Optimism), dominated by Base + mainnet. Issue #2275 explicitly asked for the narrowest thing that fixes.box, so this watches the one known proxy resolver.A survey of all 1294 TLDs (root registry domains) via Omnigraph, cross-checked against on-chain
supportsInterface+ the EIP-1967 impl slot, confirms the scope is sufficient at the TLD level:extendedvalue matches on-chain — no stale-false resolvers. The onlyfalseTLD is.eth, whose resolver is a plain non-wildcard PublicResolver (correctlyfalse, not a proxy).0xf97aac…(box / 3DNS) is the only EIP-1967 proxy among all 1294 TLD resolvers. The dominant DNSSEC resolver (1286 TLDs,0xf142b308…) and the rest are plain non-upgradeable contracts.Deeper (2LD) wildcard resolvers were not surveyed; the address-allowlist can be extended if a proxy resolver shows up there.
Testing
pnpm typecheck(all workspaces),pnpm lint,pnpm test— green.cast-verifiedsupportsInterface+ EIP-1967 impl slot for every distinct TLD resolver.Notes