feat(ensindexer): per-chain eth_getLogs block range via ETH_GET_LOGS_BLOCK_RANGE_<chainId>#2222
feat(ensindexer): per-chain eth_getLogs block range via ETH_GET_LOGS_BLOCK_RANGE_<chainId>#2222Quantumlyy wants to merge 12 commits into
Conversation
Add an ENSIndexer-local mechanism, parallel to RPC_URL_<chainId>, that parses optional per-chain ETH_GET_LOGS_BLOCK_RANGE_<chainId> environment variables into config.ethGetLogsBlockRanges (Map<ChainId, number>), validated as positive integers and surfaced in the redacted config serialization. Kept separate from the shared SDK RpcConfig (used by ENSApi, which runs no Ponder). Not yet consumed by the Ponder config; that follows in a later commit.
Thread config.ethGetLogsBlockRanges into the Ponder chains config. The two chain-config helpers now take an EnsIndexerConfig slice instead of just rpcConfigs, and chainsConnectionConfig sets chains[id].ethGetLogsBlockRange only when an override is configured (otherwise Ponder auto-determines the range). Because Ponder's Build ID excludes config.chains, configuring a block range does not change the Build ID and does not trigger a re-index, just like RPC_URL.
Document the per-chain ETH_GET_LOGS_BLOCK_RANGE_<chainId> override in .env.local.example (embedded into the configuration docs) and the docker env example, and add a changeset.
🦋 Changeset detectedLatest commit: 35a373c 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 |
|
@Quantumlyy is attempting to deploy a commit to the NameHash Team on Vercel. A member of the Team first needs to authorize it. |
📝 WalkthroughWalkthroughAdds per-chain ChangesPer-chain eth_getLogs block range overrides
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
🚥 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 SummaryAdds per-chain and global
Confidence Score: 5/5Safe to merge — the change is purely additive, excluded from Ponder's build ID so it cannot trigger a re-index, and fully isolated to ENSIndexer. The env-to-config pipeline is well-tested (builder, schema, config integration, and Ponder chain config wiring each have dedicated tests). The No files require special attention. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
ENV["Process Environment"] --> GLOBAL["ETH_GET_LOGS_BLOCK_RANGE\n(global default)"]
ENV --> CHAIN["ETH_GET_LOGS_BLOCK_RANGE_chainId\n(per-chain override)"]
GLOBAL & CHAIN --> BUILD["buildEthGetLogsBlockRangesFromEnv(env, namespace)"]
BUILD --> SCOPE{"Chain in\nnamespace?"}
SCOPE -- "No" --> SKIP["Ignored"]
SCOPE -- "Yes" --> RESOLVE{"Per-chain\nvar set?"}
RESOLVE -- "Yes (including 0)" --> USE_CHAIN["Use chain-specific value"]
RESOLVE -- "No" --> USE_DEFAULT["Use global default\n(if set)"]
USE_CHAIN & USE_DEFAULT --> RAW["Record ChainIdString string"]
RAW --> SCHEMA["EthGetLogsBlockRangesSchema\n(zod parse + transform)"]
SCHEMA --> VALIDATE{"Value > 0?"}
VALIDATE -- "Yes" --> MAP["Map.set(chainId, blockRange)"]
VALIDATE -- "No (0 = disable)" --> DROP["Omit - Ponder\nauto-determines"]
MAP --> RESULT["Map ChainId number\nethGetLogsBlockRanges"]
RESULT --> PONDER["chainsConnectionConfig()"]
PONDER --> PONDER_CFG["Ponder Config chains"]
Reviews (7): Last reviewed commit: "Merge branch 'main' into Quantumlyy/per-..." | Re-trigger Greptile |
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
Add a global ETH_GET_LOGS_BLOCK_RANGE applied to every chain, with each ETH_GET_LOGS_BLOCK_RANGE_<chainId> overriding it per chain and a value of 0 disabling the override for that chain (so Ponder auto-determines its range). ETH_GET_LOGS_BLOCK_RANGE=0 is equivalent to unset. Values resolve into the existing per-chain effective map, so the Ponder chains wiring is unchanged.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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/.env.local.example`:
- Around line 117-123: The documentation is contradictory about allowed values
for ETH_GET_LOGS_BLOCK_RANGE: change the wording to state that
ETH_GET_LOGS_BLOCK_RANGE and ETH_GET_LOGS_BLOCK_RANGE_${chainId} accept a
non-negative integer (0 included), and clarify that 0 disables the override so
Ponder auto-determines the range; also state that ETH_GET_LOGS_BLOCK_RANGE=0 is
equivalent to leaving it unset.
🪄 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: dee74bdf-27af-4bf0-9df1-6eab36032e0d
📒 Files selected for processing (8)
.changeset/eth-getlogs-block-range.mdapps/ensindexer/.env.local.exampleapps/ensindexer/src/config/config.test.tsapps/ensindexer/src/config/environment.tsapps/ensindexer/src/config/eth-get-logs-block-ranges.test.tsapps/ensindexer/src/config/eth-get-logs-block-ranges.tsapps/ensindexer/src/config/types.tsdocker/envs/.env.docker.example
The value-type line said "positive integer", which contradicted the documented 0-disables behavior. State that the value is a non-negative integer (0 included) and that 0 disables the override so Ponder auto-determines the range.
Summary
eth_getLogsblock range, configured via environment variables:ETH_GET_LOGS_BLOCK_RANGEsets a default applied to every chain.ETH_GET_LOGS_BLOCK_RANGE_<chainId>overrides that default for a specific chain (analogous toRPC_URL_<chainId>).ETH_GET_LOGS_BLOCK_RANGE_<chainId>=0disables the cap for that chain so Ponder auto-determines its range;ETH_GET_LOGS_BLOCK_RANGE=0is equivalent to unset.chainsconfig; chains without an effective cap keep Ponder's default behavior..env.local.example(embedded in the configuration docs) and the docker env example; changeset included.Why
eth_getLogsblock range, which can stall indexing for a chain. ENSIndexer had no way to cap it; this adds a global default plus per-chain overrides (and a per-chain opt-out) without affecting other chains.Testing
pnpm -F ensindexer typecheck,pnpm lint:ci, andpnpm generate(no drift) pass; theensindexertest suite is green.0disable), env→config resolution (config.test.ts), andchainsConnectionConfigasserting the option is absent when unset/disabled and present when configured (ponder-helpers.test.ts).Notes for Reviewer (Optional)
ponder@0.16.6that the Build ID hashes only{ordering, contracts, accounts, blocks}and excludesconfig.chains, so these behave exactly likeRPC_URL(changing them never forces a re-index). They are deliberately kept out ofIndexingBehaviorInjectionContract, which injects into the hashedconfig.contracts.RpcConfig.RpcConfig/RpcEnvironment/buildRpcConfigsFromEnvare shared with ENSApi (which runs no Ponder), so the knob lives in a new app-localEthGetLogsBlockRangeEnvironment+ethGetLogsBlockRangesconfig field. No SDK / public-config / OpenAPI change.0disable are resolved at config-build time into the effective per-chainethGetLogsBlockRangesmap, so thechainsConnectionConfigwiring stays a simple per-chain lookup.Pre-Review Checklist (Blocking)