feat(ensnode-sdk): introduce EnsIndexerClient#1643
Merged
Conversation
The goal of this change is to apply deserialization protocol where data is first transformed into serialized data model in order to be deserialized to business data model.
The goal of this change is to apply deserialization protocol where data is first transformed into serialized data model in order to be deserialized to business data model.
Follows `EnsApiClient` class, but is limited to only two methods: `config()` and `indexingStatus()`.
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub.
2 Skipped Deployments
|
🦋 Changeset detectedLatest commit: 55b839c The changes in this PR will be included in the next version bump. This PR includes changesets to release 19 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 |
📝 WalkthroughWalkthroughAdds a new exported EnsIndexerClient and a public ENSIndexer API layer: config and indexing-status endpoints, serialized types, serializers/deserializers, Zod validation schemas, shared error handling, mocks/tests, and updated barrel re-exports to expose the new client and API surface. (48 words) Changes
Sequence Diagram(s)sequenceDiagram
participant C as EnsIndexerClient
participant S as ENSIndexer HTTP
participant P as JSON Parser
participant V as Zod Validator
participant D as Deserializer
C->>S: GET /api/config or /api/indexing-status
S-->>C: HTTP response (JSON payload)
C->>P: parse JSON
P-->>C: unvalidated object
C->>V: validate with appropriate Zod schema
V-->>C: validated or validation error
alt Validation Success
C->>D: deserialize (may enrich realtimeProjection)
D-->>C: typed EnsIndexer*Response
C-->>C: return typed response
else Validation Failure
V-->>C: prettified Zod error
C-->>C: throw Error with details
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 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 |
…teracting with ENSIndexer APIs.
Contributor
Author
|
@greptile review |
Contributor
Greptile SummaryThis PR introduces Key observations:
Confidence Score: 4/5
Important Files Changed
Sequence DiagramsequenceDiagram
participant C as Caller
participant EIC as EnsIndexerClient
participant F as fetch()
participant DE as deserializeErrorResponse
participant DC as deserializeEnsIndexerConfigResponse
participant DIS as deserializeEnsIndexerIndexingStatusResponse
C->>EIC: config()
EIC->>F: fetch(/api/config)
F-->>EIC: Response
alt JSON parse fails
EIC-->>C: throw "Malformed response data: invalid JSON"
else !response.ok
EIC->>DE: deserializeErrorResponse(body)
DE-->>EIC: ErrorResponse
EIC-->>C: throw "Fetching ENSIndexer Config Failed: ..."
else response.ok
EIC->>DC: deserializeEnsIndexerConfigResponse(body)
DC-->>EIC: EnsIndexerConfigResponse
EIC-->>C: EnsIndexerConfigResponse
end
C->>EIC: indexingStatus()
EIC->>F: fetch(/api/indexing-status)
F-->>EIC: Response
alt JSON parse fails
EIC-->>C: throw "Malformed response data: invalid JSON"
else !response.ok
EIC->>DE: deserializeErrorResponse(body)
alt body matches ErrorResponseSchema
DE-->>EIC: ErrorResponse
EIC-->>C: throw "Fetching ENSIndexer Indexing Status Failed: ..."
else body does NOT match ErrorResponseSchema
DE-->>EIC: throws (caught, no-op)
EIC->>DIS: deserializeEnsIndexerIndexingStatusResponse(body)
DIS-->>EIC: EnsIndexerIndexingStatusResponseError
EIC-->>C: EnsIndexerIndexingStatusResponseError
end
else response.ok
EIC->>DIS: deserializeEnsIndexerIndexingStatusResponse(body)
DIS-->>EIC: EnsIndexerIndexingStatusResponseOk
EIC-->>C: EnsIndexerIndexingStatusResponseOk
end
Last reviewed commit: f8b9fec |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Pull request overview
This PR introduces the EnsIndexerClient class to the ENSNode SDK, enabling programmatic access to ENSIndexer's configuration and indexing status APIs. This client follows the same architectural patterns as the existing EnsApiClient and is part of the effort described in issue #1252 to improve the communication between ENSApi and ENSIndexer services.
Changes:
- Adds
EnsIndexerClientclass withconfig()andindexingStatus()methods - Implements API response types, schemas, and serialization/deserialization functions for ENSIndexer's config and indexing-status endpoints
- Adds error response handling following established patterns
- Includes test coverage for happy path scenarios and mock data
Reviewed changes
Copilot reviewed 21 out of 21 changed files in this pull request and generated 11 comments.
Show a summary per file
| File | Description |
|---|---|
packages/ensnode-sdk/src/ensindexer/client.ts |
Core client implementation with config() and indexingStatus() methods |
packages/ensnode-sdk/src/ensindexer/client.test.ts |
Unit tests for the client (happy paths) |
packages/ensnode-sdk/src/ensindexer/client.mock.ts |
Mock data for testing |
packages/ensnode-sdk/src/ensindexer/api/shared/errors/* |
Error response types, schemas, and deserialization |
packages/ensnode-sdk/src/ensindexer/api/indexing-status/* |
Indexing status API types, schemas, serialization/deserialization |
packages/ensnode-sdk/src/ensindexer/api/config/* |
Config API types, schemas, serialization/deserialization |
packages/ensnode-sdk/src/ensindexer/api/index.ts |
API exports aggregation |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
![vercel[bot]](https://avatars.githubusercontent.com/in/8329?s=60&v=4){kind=small}
Contributor
Author
|
@greptile review |
![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
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/ensnode-sdk/src/ensapi/client.ts (1)
370-383: 🛠️ Refactor suggestion | 🟠 MajorInconsistent error-handling pattern: no-op here vs.
console.login sibling methods.The
catchblock here was changed to a silent no-op comment, butregistrarActions()(Line 597) andnameTokens()(Line 668) still useconsole.login the equivalent catch block. These should be aligned — either all use no-op or all log.♻️ Suggested fix — align registrarActions and nameTokens
In
registrarActions()(~line 594-598):} catch { - // if errorResponse could not be determined, - // it means the response includes data - console.log("Registrar Actions API: handling a known server error."); + // No-op: allow subsequent deserialization of registrar actions response. }In
nameTokens()(~line 665-669):} catch { - // if errorResponse could not be determined, - // it means the response includes data - console.log("Name Tokens API: handling a known server error."); + // No-op: allow subsequent deserialization of name tokens response. }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/ensnode-sdk/src/ensapi/client.ts` around lines 370 - 383, The three error-handling catch blocks should be consistent: update registrarActions() and nameTokens() to match the silent no-op pattern used around the deserializeErrorResponse() logic in the indexing-status path; specifically, replace the console.log calls in the catch blocks inside registrarActions and nameTokens with the same empty catch/no-op comment used where deserializeErrorResponse(responseData) is attempted (the ErrorResponse, deserializeErrorResponse and responseData handling), so all three locations use the same silent fallback before attempting subsequent deserialization and then conditionally throwing based on errorResponse.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@packages/ensnode-sdk/src/ensindexer/client.test.ts`:
- Around line 77-88: The test is mocking a non-OK ErrorResponse but uses the
wrong field name; update the mock so the payload matches the ErrorResponse
schema (use a "message" field) so that deserializeErrorResponse is exercised.
Specifically, in the test for client.indexingStatus(), change the mocked
errorResponse to include message: string (not error) so
deserializeErrorResponse(path) will validate and the code path that throws the
parsed error is tested instead of falling back to
deserializeEnsIndexerConfigResponse; ensure mockFetch.mockResolvedValueOnce
still returns ok: false and json() resolving to that corrected object.
In `@packages/ensnode-sdk/src/ensindexer/client.ts`:
- Around line 72-91: The config() handler currently falls through to
deserializeEnsIndexerConfigResponse when response.ok is false and
deserializeErrorResponse throws, which masks the HTTP error; update config() so
that any non-OK response always results in throwing an error: attempt to
deserializeErrorResponse and, if successful, throw with errorResponse.message,
otherwise throw a generic HTTP error that includes response.status (and
optionally response.statusText or the raw responseData) so the HTTP context
isn't lost; reference the config() function and the deserializeErrorResponse /
deserializeEnsIndexerConfigResponse calls and mirror the intent used in
indexingStatus() but always abort on non-OK.
---
Outside diff comments:
In `@packages/ensnode-sdk/src/ensapi/client.ts`:
- Around line 370-383: The three error-handling catch blocks should be
consistent: update registrarActions() and nameTokens() to match the silent no-op
pattern used around the deserializeErrorResponse() logic in the indexing-status
path; specifically, replace the console.log calls in the catch blocks inside
registrarActions and nameTokens with the same empty catch/no-op comment used
where deserializeErrorResponse(responseData) is attempted (the ErrorResponse,
deserializeErrorResponse and responseData handling), so all three locations use
the same silent fallback before attempting subsequent deserialization and then
conditionally throwing based on errorResponse.
---
Duplicate comments:
In `@packages/ensnode-sdk/src/ensindexer/client.test.ts`:
- Around line 42-57: Add tests covering config() error paths: create three new
it() cases that call client.config() and assert it rejects appropriately when
(1) the mocked fetch returns { ok: false, json: async () => validErrorBody } —
assert the thrown error includes/parses that body, (2) fetch returns { ok:
false, json: async () => { throw new Error("bad json") } } — assert the call
rejects with the json error, and (3) fetch returns { ok: false, json: async ()
=> invalidNonObject } (or other malformed body) — assert rejection/fallback
behavior. Use the same requestUrl construction and
mockFetch.mockResolvedValueOnce to stub responses, and keep assertions that
mockFetch was called with requestUrl; reference client.config(), mockFetch, and
deserializeEnsIndexerConfigResponse to locate existing test setup and
expected-shape helpers.
In `@packages/ensnode-sdk/src/ensindexer/client.ts`:
- Around line 58-137: config() and indexingStatus() duplicate the same fetch →
json → errorResponse handling → deserialization logic; add a private helper
method (e.g. fetchJson(path: string)) that performs fetch(new URL(path,
this.options.url)), awaits response.json() with the existing malformed-JSON
check, attempts deserializeErrorResponse when !response.ok and throws the same
formatted Error message if present, and otherwise returns the parsed
responseData; then refactor config() to call fetchJson('/api/config') and pass
the result into deserializeEnsIndexerConfigResponse, and refactor
indexingStatus() to call fetchJson('/api/indexing-status') and pass the result
into deserializeEnsIndexerIndexingStatusResponse, keeping existing error
messages and using the same helper for both endpoints.
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 24 out of 24 changed files in this pull request and generated 4 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@packages/ensnode-sdk/src/ensindexer/client.test.ts`:
- Around line 59-76: The test's mocked errorBody uses the wrong shape so
deserializeErrorResponse never validates and the code takes the fallthrough
path; change errorBody to match the ErrorResponse schema (top-level { message:
"Something went wrong", details?: ... }) so deserializeErrorResponse runs, then
tighten the assertion on client.config() to expect the thrown error to include
that message (e.g., await expect(client.config()).rejects.toThrow("Something
went wrong")), and keep the existing expectation that mockFetch was called with
requestUrl; reference functions/types: deserializeErrorResponse, ErrorResponse,
deserializeEnsIndexerConfigResponse, client.config(), and mockFetch.
---
Duplicate comments:
In `@packages/ensnode-sdk/src/ensindexer/client.test.ts`:
- Around line 110-121: The test uses the wrong error payload shape; update the
mocked non-OK response in the test for client.indexingStatus() to return an
ErrorResponse-shaped object { message: "Something went wrong" } (not { error:
... }) so the code takes the error-response branch, and change the assertion to
expect the specific thrown message "Fetching ENSIndexer Indexing Status Failed:
Something went wrong"; ensure the mockFetch resolution still returns ok: false
and json: async () => the new object and that the test still verifies mockFetch
was called with the requestUrl.
Contributor
Author
|
@greptile review |
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 25 out of 25 changed files in this pull request and generated 4 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| * | ||
| * @throws if the ENSApi request fails | ||
| * @throws if the ENSApi returns an error response | ||
| * @throws if the ENSIndexer returns a non-ok response |
There was a problem hiding this comment.
JSDoc for EnsApiClient.config() incorrectly says it may throw when the ENSIndexer returns a non-ok response, but this client calls ENSApi. Update the @throws description to reference ENSApi (or "server") to avoid misleading SDK consumers.
Suggested change
| * @throws if the ENSIndexer returns a non-ok response | |
| * @throws if the ENSApi returns a non-ok response |
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/ensnode-sdk/src/ensapi/client.ts (1)
370-383: 🧹 Nitpick | 🔵 TrivialLogging inconsistency:
registrarActions()andnameTokens()still emitconsole.login the equivalent catch block.Line 376 now silently no-ops when
deserializeErrorResponsethrows, but the analogous catch paths inregistrarActions()(line 598) andnameTokens()(line 668) still callconsole.log(...). Either remove those two surviving logs or restore the log here for consistency.♻️ Proposed clean-up for the sibling catch blocks (registrarActions / nameTokens)
- } catch { - // if errorResponse could not be determined, - // it means the response includes data - console.log("Registrar Actions API: handling a known server error."); - } + } catch { + // No-op: allow subsequent deserialization of registrar actions response. + }- } catch { - // if errorResponse could not be determined, - // it means the response includes data - console.log("Name Tokens API: handling a known server error."); - } + } catch { + // No-op: allow subsequent deserialization of name tokens response. + }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/ensnode-sdk/src/ensapi/client.ts` around lines 370 - 383, The error-deserialization catch in the indexing status fetch (using deserializeErrorResponse) swallows errors silently, but the sibling functions registrarActions and nameTokens still call console.log in their equivalent catch blocks, creating inconsistency; update the code so all three behave the same: either remove the console.log(...) calls from registrarActions and nameTokens or add a console.log here inside the catch that mirrors their existing message. Locate the catch that surrounds deserializeErrorResponse in client.ts (the response.ok error-handling block) and make the chosen change, ensuring you reference deserializeErrorResponse, registrarActions, and nameTokens so all three error-paths are consistent.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@packages/ensnode-sdk/src/ensindexer/client.ts`:
- Around line 72-75: The config() path currently calls
deserializeErrorResponse(responseData) without guarding, so a malformed error
body can throw a Zod error and lose HTTP status; wrap the
deserializeErrorResponse call in a try/catch (same pattern used in
indexingStatus()), and on failure fall back to a generic error that includes the
HTTP status (response.status / response.statusText) and the raw responseData;
ensure you still throw an Error with a clear message like "Fetching ENSIndexer
Config Failed" combined with either errorResponse.message or the fallback
information so callers receive the HTTP status and body when deserialization
fails.
---
Outside diff comments:
In `@packages/ensnode-sdk/src/ensapi/client.ts`:
- Around line 370-383: The error-deserialization catch in the indexing status
fetch (using deserializeErrorResponse) swallows errors silently, but the sibling
functions registrarActions and nameTokens still call console.log in their
equivalent catch blocks, creating inconsistency; update the code so all three
behave the same: either remove the console.log(...) calls from registrarActions
and nameTokens or add a console.log here inside the catch that mirrors their
existing message. Locate the catch that surrounds deserializeErrorResponse in
client.ts (the response.ok error-handling block) and make the chosen change,
ensuring you reference deserializeErrorResponse, registrarActions, and
nameTokens so all three error-paths are consistent.
---
Duplicate comments:
In `@packages/ensnode-sdk/src/ensindexer/client.test.ts`:
- Around line 42-89: Add a test that covers the branch where client.config()
receives response.ok === false but the response body does not match
ErrorResponseSchema so deserializeErrorResponse throws: mockFetch to resolve
with ok: false and a json() that returns an invalid object (e.g., { foo: "bar" }
or throws when validating), then assert that client.config() rejects with the
deserializeErrorResponse error (use rejects.toThrow matching the deserializer's
error message or type) and that mockFetch was called with the same requestUrl;
this targets the unguarded call path involving deserializeErrorResponse in
client.config().
- Around line 59-74: Tighten the test assertion in client.config() to assert the
exact error message emitted after deserializeErrorResponse runs: update the
rejects.toThrow check in the "throws an error when the config endpoint returns a
non-OK response with a valid error body" test so it expects the full message
that includes errorBody.message (e.g., "Fetching ENSIndexer Config Failed:
Something went wrong"), ensuring deserializeErrorResponse actually contributed
its message; keep the existing mockFetch setup and the
expect(mockFetch).toHaveBeenCalledWith(requestUrl) assertion intact and
reference this change around the test for client.config and the
deserializeErrorResponse code path.
In `@packages/ensnode-sdk/src/ensindexer/client.ts`:
- Around line 58-103: Both config() and indexingStatus() duplicate the fetch →
response.json() → invalid-JSON error pattern; extract a shared helper (e.g.,
fetchAndParseJson or fetchJson) used by both methods to reduce duplication. The
helper should accept the endpoint path (or URL), perform fetch(url), attempt
response.json() inside try/catch and rethrow new Error("Malformed response data:
invalid JSON") on parse failure, then return an object containing { response,
responseData } so callers (config() and indexingStatus()) can check response.ok,
deserialize errors with deserializeErrorResponse(responseData) and call the
existing deserializeEnsIndexerConfigResponse /
deserializeEnsIndexerIndexingStatusResponse with the appropriately typed
responseData (keeping Unvalidated typing). Replace the duplicated blocks in
config() and indexingStatus() to call this helper and preserve existing error
messages and behavior.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Lite PR
Tip: Review docs on the ENSNode PR process
Summary
EnsIndexerClientis introduced to ENSNode SDKWhy
EnsIndexerClientto fetch data about related ENSIndexer instance.Testing
Notes for Reviewer (Optional)
Pre-Review Checklist (Blocking)