feat(ensindexer): ENSDb Writer Worker #1406

tk-o · 2025-12-16T17:35:08Z

Store ENSNode metadata (ENSIndexer Public Config, Indexing Status) into ENSDb.

Suggested review order

ENSNode Schema

New schema was added for ENSNode metadata at packages/ensnode-schema/src/schemas/ensnode-metadata.schema.ts.

ENSNode SDK

A simple HTTP client was built at packages/ensnode-sdk/src/ensindexer/client.ts. It's useful for sending HTTP requests over the internal network (akin to in-memory function calls):

/health endpoint — required to respond with HTTP Status OK before any other requests can be made.
/api/config endpoint — returns in-memory ENSIndexerPublicConfig object.
/api/indexing/status endpoint — returns in-memory IndexingStatusResponse object.

ENSIndexer

ENSDb module

Includes:

makeDrizzle factory function known from ENSApi, which creates a Drizzle client instance.
- apps/ensindexer/src/lib/ensdb/drizzle.ts
ENSNodeMetadata type defining data model associated with ensnode-metadata.schema.ts
- apps/ensindexer/src/lib/ensdb/ensnode-metadata.ts
EnsDbClient class for performing ENSDb reads and writes.
- apps/ensindexer/src/lib/ensdb/ensdb-client.ts

ENSDb Writer Worker

Initialized at ENSIndexer process startup:

apps/ensindexer/ponder/src/ensdb-writer-worker.ts

Waits for ENSIndexer to become healthy and then:

Attempts to upsert ENSIndexerPublicConfig into ENSDb.
- This may fail when ENSDb already had other record for ENSIndexerPublicConfig stored before, and the new record was not compatible with the stored one.
- This is a single attempt and if it fails, the ENSIndexer application will be terminated with error.
- Also, the ENSDb Version info is stored into ENSDb at the same time as ENSIndexerPublicConfig record.
Attempts to upsert CrossChainIndexingStatusSnapshot into ENSDb.

This may fail if the indexing status was not available yet, or the omnichain indexing status was "unstarted".
This is a recurring attempt; any failed attempt will log an error and there will be another attempt.

Related to #1252

Store ENSNode metadata (ENSIndexer Public Config, Indexing Status) into ENSDb.

changeset-bot · 2025-12-16T17:35:12Z

🦋 Changeset detected

Latest commit: 57fcd2a

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 14 packages

Name	Type
ensindexer	Minor
@ensnode/ensnode-schema	Minor
ensadmin	Minor
ensapi	Minor
ensrainbow	Minor
@ensnode/datasources	Minor
@ensnode/ensrainbow-sdk	Minor
@ensnode/ponder-metadata	Minor
@ensnode/ensnode-react	Minor
@ensnode/ponder-subgraph	Minor
@ensnode/ensnode-sdk	Minor
@ensnode/shared-configs	Minor
@docs/ensnode	Minor
@docs/ensrainbow	Minor

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

vercel · 2025-12-16T17:35:13Z

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Review	Updated (UTC)
admin.ensnode.io	Ready	Preview, Comment	Dec 18, 2025 3:12pm
ensnode.io	Ready	Preview, Comment	Dec 18, 2025 3:12pm
ensrainbow.io	Ready	Preview, Comment	Dec 18, 2025 3:12pm

…ations of ENSIndexer Public Config and Indexing Status to ENSDb.

shrugs · 2025-12-17T16:49:33Z

apps/ensindexer/ponder/src/ensdb-writer-worker.ts

+  await waitForEnsIndexerToBecomeHealthy;
+
+  // 1. Create ENSDb Client
+  const ensDbConnection = new EnsDbConnection();


nitpick, but i would name these connection, client, query and mutation given the existing context, it feels cleaner and more straightforward. wdyt?

shrugs · 2025-12-17T16:50:52Z

apps/ensindexer/ponder/src/ensdb-writer-worker.ts

+    // Read stored config and in-memory config.
+    // Note: we wrap read operations in pRetry to ensure all of them are
+    // completed successfully.
+    const [storedConfig, inMemoryConfig] = await pRetry(() =>


technically it think this should be

await Promise.all([ pRetry(...), pRetry(...) ])

this way if one of the reads fails, the other isn't unnecessarily re-fetched

Awesome suggestion, thanks 🚀

shrugs · 2025-12-17T16:55:19Z

apps/ensindexer/ponder/src/ensdb-writer-worker.ts

+      // Upsert ENSIndexerPublicConfig into ENSDb.
+      // Note: we wrap write operation in pRetry to ensure it can complete
+      // successfully, as there will be no other attempt.
+      await pRetry(() => ensDbMutation.upsertEnsIndexerPublicConfig(inMemoryConfig));


in what conditions would this write fail that would be retry-able? perhaps pRetry is unnecessary here, and it would be more exact to require that this promise succeed on its first attempt

I didn't feel 100% ok with this pRetry, perhaps we should the process fail if there's any (very unlikely) issue with the write 👍

shrugs · 2025-12-17T16:57:40Z

apps/ensindexer/ponder/src/ensdb-writer-worker.ts

+
+      // Check if Indexing Status is in expected status.
+      if (omnichainSnapshot.omnichainStatus === OmnichainIndexingStatusIds.Unstarted) {
+        throw new Error("Omnichain Status  must be different that 'Unstarted'.");


than* unstarted

shrugs · 2025-12-17T16:58:51Z

apps/ensindexer/ponder/src/ensdb-writer-worker.ts

+      // Upsert ENSIndexerPublicConfig into ENSDb.
+      await ensDbMutation.upsertIndexingStatus(snapshot);
+
+      logger.info("Indexing Status successfully stored in ENSDb.");


add a once-per-process log at info level for "Indexing Status successfully stored in ENSDb."

make this a trace-level call with something like "Indexing Status updated in ENSDb."

In fact, there's no need to log the trace for the update event. The lack of error log implies the successful update.

shrugs · 2025-12-17T19:18:46Z

apps/ensindexer/src/lib/ensdb/drizzle.ts

@@ -0,0 +1,41 @@
+// This file was copied 1-to-1 from ENSApi.


it doesn't seem trivial or possible to deduplicate this into ensnode-sdk, so let's wait until we have an ensnode-internal package or something to dry this up — can you add a TODO here indicating that? like

// TODO: deduplicate with apps/ensapi/src/lib/handlers/drizzle.ts when ensnode nodejs internal package is created

likewise for logger.ts

actually because ensindexer isn't using pino-formatted logs consistently, i think it might be best if we just use console.log in these cases. in which case i'd remove the debug logging in the client and let the consumer of the client handle all of the logging. in-client logging is only useful if we can indicate a log level to ignore it by default.

if you decide to keep pino in ensindexer, you'd want to add LogLevelEnvironment to the ENSIndexerEnvironment

Ok, I'm fine with using native logger from console object.

shrugs · 2025-12-17T19:20:05Z

apps/ensindexer/src/lib/ensdb/drizzle.ts

+type Schema = { [name: string]: unknown };
+
+// https://github.com/ponder-sh/ponder/blob/f7f6444ab8d1a870fe6492023941091df7b7cddf/packages/client/src/index.ts#L226C1-L239C3
+const setDatabaseSchema = <T extends Schema>(schema: T, schemaName: string) => {


import { setDatabaseSchema } from "@ponder/client"; and use that instead of this

shrugs · 2025-12-17T19:23:11Z

apps/ensindexer/src/lib/ensdb/ensdb-connection.ts

@@ -0,0 +1,63 @@
+import type { NodePgDatabase } from "drizzle-orm/node-postgres";


why are we doing all of this pooling and connection management logic? it doesn't seem necessary and introduces redirection and complexity. we only need a single connection (created by makeDrizzle) for the writer, and it's writing once a second — we don't need the parallel connections offered by pg.Pool

i'd replace this entire file with:

// in ensdb-writer-worker const client = new EnsNodeMetadataClient()`

class EnsNodeMetadataClient { db = makeDrizzle(schema) constructor() {} // or put it in the constructor, whatever typescript requires }

Right, for ENSIndexer all we need is a single connection. However, for ENSApi, we'll need to switch to connection pool to improved read-side performance 👍

gotcha! makes sense. that case I'd suggest just doing something like this

return drizzle({ client: new Pool({ connectionString: process.env.DATABASE_URL, }) })

instead of a custom connection class

shrugs · 2025-12-17T19:24:19Z

apps/ensindexer/src/lib/ensdb/ensdb-mutation.ts

+import { type EnsNodeMetadata, EnsNodeMetadataKeys } from "./ensnode-metadata";
+
+/**
+ * ENSDb Mutation


i'd merge this and the query client into a single client EnsNodeMetadataClient

Will do 👍

shrugs · 2025-12-17T19:30:53Z

apps/ensindexer/src/lib/ensindexer/client.ts

+      logger.debug("Fetching ENSIndexer Health status: healthy");
+    } catch {
+      const errorMessage = "Health endpoint for ENSIndexer is not available yet.";
+      logger.error(errorMessage);


i don't think the client should log errors — the consumer should

Remove logs from ENSIndexerClient class

consolidate ensdb modules; replace pino logger with native console logger; simplify ensdb worker logic

shrugs

LGTM!

shrugs · 2025-12-17T22:57:33Z

apps/ensindexer/ponder/src/ensdb-writer-worker.ts

+  );
+}
+
+// Run ENSDb Writer Worker in a non-blocking way to


nit: just "Run ENSDb Writer Worker in the background"?

lightwalker-eth

@tk-o Thanks for this. Reviewed and shared feedback 👍

lightwalker-eth · 2025-12-17T22:00:22Z

apps/ensindexer/src/lib/ensindexer/client.ts

+  SerializedIndexingStatusResponse,
+} from "@ensnode/ensnode-sdk";
+
+export class EnsIndexerClient {


I imagine this should move into the ensnode-sdk package?

It's true that we would only use it ourselves within ENSIndexer, but in theory we should put the clients for each of the ENSNode apps into ensnode-sdk. At least with my current mental model.

It's a lot of file changes so I prefer to make this update in a follow-up PR. This move will require solving additional complexities. We'll need to split request and response types between EnsIndexerClient and ENSNodeClient. I think we should rename ENSNodeClient to EnsApiClient. ENSNode is a term describing a logical group of services. The client requires specific service as its target, hence, EnsApiClient for the EnsApi service.

Ok, I was able to move the EnsIndexerClient to ENSNode SDK package 👍

packages/ensnode-schema/src/ponder.schema.ts

packages/ensnode-schema/src/schemas/ensnode-metadata.schema.ts

pnpm-workspace.yaml

packages/ensnode-sdk/src/ensindexer/config/compatibility.ts

packages/ensnode-sdk/src/ensindexer/config/compatibility.test.ts

apps/ensindexer/ponder/src/ensdb-writer-worker.ts

lightwalker-eth · 2025-12-18T07:26:45Z

apps/ensindexer/ponder/src/ensdb-writer-worker.ts

+  console.log("ENSDb Writer Worker: ENSIndexer is healthy, starting tasks.");
+
+  // 1. Create ENSDb Client
+  const ensDbClient = new EnsDbClient();


Hmm. I think we need to give more of a detailed focus on the case of a completely fresh DATABASE_SCHEMA and how this is initialized by Ponder.

We have the existing code path:

ENSIndexer fetches ENSRainbow config from ENSRainbow

ENSIndexer can now build its own config

ENSIndexer uses its own config to build a Ponder config

Ponder uses the Ponder config to initialize DATABASE_SCHEMA.

ENSIndexer now writes metadata into the given DATABASE_SCHEMA.

Right? Don't we need to wait until step 4 for the tables in DATABASE_SCHEMA to be initialized before we can perform step 5?

Assuming so, this waiting potentially needs to grow a lot if we add logic to wait up to an hour for step 1 above to be complete, waiting for ENSRainbow to become both healthy and ready.

And during all of this time, what is ENSApi supposed to do? From its perspective, it's been configured to read from DATABASE_SCHEMA but ENSIndexer might wait over an hour to create it.

One idea is that maybe we don't want to write at all to DATABASE_SCHEMA and instead we create our own database schema name that is always used by ENSNode instances writing to a particular Postgres database, kind of how Ponder sync works and how it can be shared across multiple Ponder instances at the same time. If we took this path we would need to update the data model so that multiple ENSNode instances could operate in parallel without impacting each others state. There's a meaningful amount of complexity here and we need to be careful not to mess it up. I don't have a strong opinion at the moment on the solution, above is just a quick brainstorm.

One thing that maybe could help here is to fix the situation where ENSIndexer can't initialize Ponder for more than an hour. Maybe we can make it so that ENSRainbow returns its config even before it is ready and as soon as it is healthy (which I imagine should be super fast?). If so then Ponder might be able to initialize the DATABASE_SCHEMA super fast, which would then allow us to start writing some symbolic value into the metadata tables that represents waiting for ENSRainbow to initialize which could then be read and understood by ENSApi during its own initialization phase. If we took this path then we need some strategy for what to do with Ponder's desire to just immediately start indexing as soon as we pass it its config. Is there a way to tell Ponder to initialize the database but don't start indexing yet?

Suggest to take a step back and carefully consider all cases and situations, then to document a plan and share it with the team for review 👍 Please feel welcome to challenge all the ideas I shared above.

Short answer is that all we need to to is to wait for ENSIndexer /health endpoint to return 200 OK response.

Here are example logs from ponder application when database schema needs to be initialized:

12:54:08 PM INFO database Using database schema 'public' 12:54:09 PM INFO database Created tables [ensnode_metadata, reverse_name_records, node_resolver_relations, resolver_records, resolver_address_records, resolver_trecords, migrated_nodes, subregistries, registration_lifecycles, registrar_actions, _ensindexer_registrar_action_metadata, subgraph_domains, subgraph_accounts, subgraph_resolvers, subgraph_registrations, subgraph_wrapped_domains, subgraph_transfers, subgraph_new_owners, subgraph_new_resolvers, subgraph_new_ttls, subgraph_wrapped_transfers, subgraph_name_wrapped, subgraph_name_unwrapped, subgraph_fuses_set, subgraph_expiry_extended, subgraph_name_registered, subgraph_name_renewed, subgraph_name_transferred, subgraph_addr_changed, subgraph_multicoin_addr_changed, subgraph_name_changed, subgraph_abi_changed, subgraph_pubkey_changed, subgraph_text_changed, subgraph_contenthash_changed, subgraph_interface_changed, subgraph_authorisation_changed, subgraph_version_changed, name_sales, name_tokens] 12:54:09 PM INFO server Started listening on port 42069 12:54:09 PM INFO server Started returning 200 responses from /health endpoint

Please note how ponder first create tables, and only then starts returning 200 OK response from its /health endpoint.

I like the idea for ENSApi to use specific DATABASE_SCHEMA. Suggest sticking to that. This way we can keep wrap the whole scope of ENSDb inside a single database schema — it's a very convenient assumption.

ENSApi has to wait for ENSDb to include EnsNodeMetadata. Otherwise, there's literally no use case ENSApi could serve. All ENSApi routes require indexing status information, which come from ENSDb.

ENSDb won't have the EnsNodeMetadata information until ENSIndexer stores it.

ENSIndexer won't store any EnsNodeMetadata information until ENSRainbow is healthy, and ENSIndexer is healthy.

I think we should create a "logical healthcheck" for ENSDb, such that clients connecting to ENSDb could know if the service is ready to be used. For example, we can consider this "logical healthcheck" to ensure that ENSDb includes EnsNodeMetadata for both keys: EnsNodeMetadataKeys.EnsIndexerPublicConfig, EnsNodeMetadataKeys.IndexingStatus.

@tk-o Overall agreed, but with a few distinctions:

Suggest to separate the idea of "healthy" vs "ready".

For an ENSDb client created with a given DATABASE_URL, DATABASE_SCHEMA, and expected database version value:

It seems we might want to have some extremely simple operation (independent of DATABASE_SCHEMA where we just check if we can connect to the DATABASE_URL at all). Or maybe this should also check that DATABASE_SCHEMA exists too? Not sure right now. But anyway.. in my mind this is the definition of "healthy".

We can have a different operation that requires that all 3 of the expected keys in the metadata table to be successfully read and deserialized AND for the key for the ENSDb version to match the expected version in the ENSDbClient. This operation could be defined as "ready".

What do you think?

These ideas might also influence how ENSApi implements both its /health and /ready APIs.

apps/ensindexer/ponder/src/ensdb-writer-worker.ts

…ation logic

tk-o · 2025-12-18T12:06:03Z

lightwalker-eth

@tk-o Thanks for updates. Reviewed and shared feedback.

packages/ensnode-schema/src/schemas/ensnode-metadata.schema.ts

lightwalker-eth · 2025-12-19T14:35:23Z

packages/ensnode-schema/src/schemas/ensnode-metadata.schema.ts

+ * Possible key value pairs are defined by 'EnsNodeMetadata' type:
+ * - `EnsNodeMetadataEnsDbVersion`
+ * - `EnsNodeMetadataEnsIndexerPublicConfig`
+ * - `EnsNodeMetadataIndexingStatus`


Suggested change

* Possible key value pairs are defined by 'EnsNodeMetadata' type:

* - `EnsNodeMetadataEnsDbVersion`

* - `EnsNodeMetadataEnsIndexerPublicConfig`

* - `EnsNodeMetadataIndexingStatus`

* Possible key value pairs are defined in the `EnsNodeMetadata` type.

We achieved the goal just through the sentence above. If we go further by duplicating a bunch of ideas here then it becomes more difficult to maintain these comments with accuracy.

lightwalker-eth · 2025-12-19T14:37:03Z

packages/ensnode-schema/src/schemas/ensnode-metadata.schema.ts

   * Key
+   *
+   * Allowed keys:
+   * - `EnsNodeMetadataEnsDbVersion['key']`
+   * - `EnsNodeMetadataEnsIndexerPublicConfig['key']`
+   * - `EnsNodeMetadataIndexingStatus['key']`


Suggested change

* Key

*

* Allowed keys:

* - `EnsNodeMetadataEnsDbVersion['key']`

* - `EnsNodeMetadataEnsIndexerPublicConfig['key']`

* - `EnsNodeMetadataIndexingStatus['key']`

* Key. Possible keys are defined in the `EnsNodeMetadata` type.

lightwalker-eth · 2025-12-19T14:37:49Z

packages/ensnode-schema/src/schemas/ensnode-metadata.schema.ts

   * Value
   *
+   * Allowed values:
+   * - `EnsNodeMetadataEnsDbVersion['value']`
+   * - `EnsNodeMetadataEnsIndexerPublicConfig['value']`
+   * - `EnsNodeMetadataIndexingStatus['value']`
+   *
   * Guaranteed to be a JSON object.


Suggested change

* Value

*

* Allowed values:

* - `EnsNodeMetadataEnsDbVersion['value']`

* - `EnsNodeMetadataEnsIndexerPublicConfig['value']`

* - `EnsNodeMetadataIndexingStatus['value']`

*

* Guaranteed to be a JSON object.

* Value. Possible values are defined in the `EnsNodeMetadata` type.

*

* Guaranteed to be a JSON object.

lightwalker-eth · 2025-12-19T14:40:29Z

apps/ensindexer/src/lib/ensindexer/local-client.ts

+ * How many times retries should be attempted before
+ * {@link waitForEnsIndexerToBecomeHealthy} becomes a rejected promise.
+ */
+export const MAX_ENSINDEXER_HEALTHCHECK_ATTEMPTS = 5;


Suggested change

export const MAX_ENSINDEXER_HEALTHCHECK_ATTEMPTS = 5;

export const MAX_ENSINDEXER_STARTUP_HEALTHCHECK_ATTEMPTS = 5;

Is that fair?

Goal: Make it more clear that this is part of the startup process.

lightwalker-eth · 2025-12-19T16:06:45Z

packages/ensnode-sdk/src/ensindexer/config/compatibility.ts

+
+/**
+ * Validate if `configB` is compatible with `configA`, such that `configA` is
+ * a subset of `configB`.


No I don't think this is correct.

For example, consider the following case:

Config A has plugins X, Y, and Z.

Config B has plugins X and Y.

Config B is a subset of Config A, but it is not compatible. Both would have different indexing results.

lightwalker-eth · 2025-12-19T16:11:52Z

packages/ensnode-sdk/src/ensindexer/client.ts

+/**
+ * ENSIndexer Client
+ *
+ * Using this client methods requires first calling `health()` method and


Why? The client should be stateless.

lightwalker-eth · 2025-12-19T16:14:43Z

packages/ensnode-sdk/src/ensindexer/client.ts

+  /**
+   * ENSIndexer Health is unknown if the health check endpoint is unavailable.
+   */
+  Unknown: "unknown",


Can you help me understand the goal here? As I understand this would generally be an Error that would be thrown by the related function call on the client? Ex: request timeout or connection failed, etc?

lightwalker-eth · 2025-12-19T16:17:33Z

packages/ensnode-sdk/src/ensindexer/client.ts

+  type SerializedIndexingStatusResponse,
+} from "@ensnode/ensnode-sdk";
+
+export const EnsIndexerHealthCheckResults = {


Can you help me understand the big idea here? Ideally all endpoints of all of our apps would return the same standard JSON response schema, where only some field such as data on a successful response has a dynamic type.

The /health endpoint of all apps should be the same.

Is there a special issue here where the /health endpoint on ENSIndexer is implemented by Ponder and not by us? If so, this logic should move into a Ponder Client class that we build.

lightwalker-eth · 2025-12-19T16:19:50Z

packages/ensnode-sdk/src/ensindexer/client.ts

+      );
+    }
+
+    if (this.#healthCheckResult !== EnsIndexerHealthCheckResults.Ok) {


Just because a client managed to get a healthy status from ENSIndexer at time T doesn't mean ENSIndexer will remain healthy at time T+N.

Clients should be stateless.

feat(ensindexer): ENSDb Writer Worker

92ad577

Store ENSNode metadata (ENSIndexer Public Config, Indexing Status) into ENSDb.

vercel bot deployed to Preview – ensrainbow.io December 16, 2025 17:35 View deployment

vercel bot deployed to Preview – ensnode.io December 16, 2025 17:35 View deployment

vercel bot deployed to Preview – admin.ensnode.io December 16, 2025 17:36 View deployment

feat(ensapi): use ENSDb query and mutation clients

43ed0e2

vercel bot deployed to Preview – ensrainbow.io December 16, 2025 22:15 View deployment

vercel bot deployed to Preview – ensnode.io December 16, 2025 22:15 View deployment

vercel bot deployed to Preview – admin.ensnode.io December 16, 2025 22:16 View deployment

tk-o changed the title ~~WIP feat(ensindexer): ENSDb Writer Worker~~ feat(ensindexer): ENSDb Writer Worker Dec 17, 2025

vercel bot deployed to Preview – ensrainbow.io December 17, 2025 13:24 View deployment

vercel bot deployed to Preview – ensnode.io December 17, 2025 13:24 View deployment

vercel bot deployed to Preview – admin.ensnode.io December 17, 2025 13:25 View deployment

feat(ensapi): improve ENSDb Writer Worker

1f362f3

tk-o force-pushed the feat/1252-write-ensnode-metadata-to-ensdb branch from ba173e1 to 1f362f3 Compare December 17, 2025 13:25

vercel bot deployed to Preview – ensrainbow.io December 17, 2025 13:25 View deployment

vercel bot deployed to Preview – admin.ensnode.io December 17, 2025 13:26 View deployment

vercel bot deployed to Preview – ensnode.io December 17, 2025 13:26 View deployment

tk-o added 2 commits December 17, 2025 14:27

docs(changeset): Includes schema for ENSNodeMetadata.

781e855

docs(changeset): Introduces a worker that writes serialized represent…

d362c24

…ations of ENSIndexer Public Config and Indexing Status to ENSDb.

tk-o marked this pull request as ready for review December 17, 2025 13:29

tk-o requested a review from a team as a code owner December 17, 2025 13:29

vercel bot deployed to Preview – ensrainbow.io December 17, 2025 13:29 View deployment

vercel bot deployed to Preview – ensnode.io December 17, 2025 13:30 View deployment

vercel bot deployed to Preview – admin.ensnode.io December 17, 2025 13:30 View deployment

feat(ensapi): tune logs

aecaf14

vercel bot deployed to Preview – ensrainbow.io December 17, 2025 15:49 View deployment

vercel bot deployed to Preview – ensnode.io December 17, 2025 15:50 View deployment

vercel bot deployed to Preview – admin.ensnode.io December 17, 2025 15:50 View deployment

shrugs reviewed Dec 17, 2025

View reviewed changes

apply pr feedback

623260f

Remove logs from ENSIndexerClient class

vercel bot deployed to Preview – ensrainbow.io December 17, 2025 20:57 View deployment

vercel bot deployed to Preview – ensnode.io December 17, 2025 20:58 View deployment

vercel bot deployed to Preview – admin.ensnode.io December 17, 2025 20:58 View deployment

tk-o force-pushed the feat/1252-write-ensnode-metadata-to-ensdb branch from c4eef67 to ed4c96e Compare December 17, 2025 21:01

vercel bot deployed to Preview – ensrainbow.io December 17, 2025 21:01 View deployment

vercel bot deployed to Preview – ensnode.io December 17, 2025 21:02 View deployment

apply pr feedback

dd19ce9

consolidate ensdb modules; replace pino logger with native console logger; simplify ensdb worker logic

vercel bot deployed to Preview – admin.ensnode.io December 17, 2025 21:02 View deployment

tk-o force-pushed the feat/1252-write-ensnode-metadata-to-ensdb branch from ed4c96e to dd19ce9 Compare December 17, 2025 21:02

vercel bot deployed to Preview – ensrainbow.io December 17, 2025 21:03 View deployment

vercel bot deployed to Preview – ensnode.io December 17, 2025 21:03 View deployment

vercel bot deployed to Preview – admin.ensnode.io December 17, 2025 21:03 View deployment

shrugs approved these changes Dec 17, 2025

View reviewed changes

lightwalker-eth reviewed Dec 18, 2025

View reviewed changes

Update EnsDbClient and EnsIndexerClient with serialization/deserializ…

e300dd9

…ation logic

tk-o added 3 commits December 18, 2025 15:35

Move EnsIndexerClient into ENSNode SDK

58d6115

Fix import paths to avoid circular dependencies

b21c67d

Include ENSDb Version in ENSNodeMetadata table

57fcd2a

vercel bot deployed to Preview – ensrainbow.io December 18, 2025 15:12 View deployment

vercel bot deployed to Preview – ensnode.io December 18, 2025 15:12 View deployment

vercel bot deployed to Preview – admin.ensnode.io December 18, 2025 15:12 View deployment

lightwalker-eth mentioned this pull request Dec 19, 2025

feat(ensapi): add openapi #1338

Draft

lightwalker-eth reviewed Dec 19, 2025

View reviewed changes

		@@ -0,0 +1,63 @@
		import type { NodePgDatabase } from "drizzle-orm/node-postgres";

	export const MAX_ENSINDEXER_HEALTHCHECK_ATTEMPTS = 5;
	export const MAX_ENSINDEXER_STARTUP_HEALTHCHECK_ATTEMPTS = 5;

feat(ensindexer): ENSDb Writer Worker #1406

Are you sure you want to change the base?

feat(ensindexer): ENSDb Writer Worker #1406

Uh oh!

Conversation

tk-o commented Dec 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Suggested review order

ENSNode Schema

ENSNode SDK

ENSIndexer

ENSDb module

ENSDb Writer Worker

Uh oh!

changeset-bot bot commented Dec 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🦋 Changeset detected

Uh oh!

vercel bot commented Dec 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

shrugs left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lightwalker-eth left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tk-o Dec 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

tk-o commented Dec 16, 2025 •

edited

Loading

changeset-bot bot commented Dec 16, 2025 •

edited

Loading

vercel bot commented Dec 16, 2025 •

edited

Loading

tk-o Dec 18, 2025 •

edited

Loading

tk-o Dec 18, 2025 •

edited

Loading

tk-o commented Dec 18, 2025 •

edited

Loading