Conversation
Renames the `topic0` column/concept to `selector` across the DB schema, indexer, GraphQL API inputs, and resolver logic. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
| Name | Type |
|---|---|
| ensapi | Major |
| ensindexer | Major |
| ensadmin | Major |
| ensrainbow | Major |
| fallback-ensapi | Major |
| @ensnode/datasources | Major |
| @ensnode/ensrainbow-sdk | Major |
| @ensnode/ensnode-schema | Major |
| @ensnode/ensnode-react | Major |
| @ensnode/ensnode-sdk | Major |
| @ensnode/ponder-sdk | Major |
| @ensnode/ponder-subgraph | Major |
| @ensnode/shared-configs | Major |
| @docs/ensnode | Major |
| @docs/ensrainbow | Major |
| @docs/mintlify | Major |
| @namehash/ens-referrals | Major |
| @namehash/namehash-ui | Major |
| @ensnode/integration-test-env | Patch |
Click here to learn what changesets are, and how to add one.
Click here if you're a maintainer who wants to add a changeset to this PR
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (5)
📝 WalkthroughWalkthroughThis PR renames the event signature field from Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes 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)
📝 Coding Plan
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 performs a clean, purely cosmetic rename of Key changes:
Note: this is a breaking change for any existing API clients that pass Confidence Score: 5/5
Important Files Changed
Sequence DiagramsequenceDiagram
participant Client as GraphQL Client
participant GQL as GraphQL Schema (event.ts)
participant Resolver as find-events-resolver.ts
participant DB as Database (ensv2.schema.ts)
Client->>GQL: query { domain { events(where: { selector_in: [...] }) } }
Note over GQL: EventsWhereInput.selector_in<br/>(was topic0_in)
GQL->>Resolver: resolveFindEvents({ where: { selector_in } })
Note over Resolver: eventsWhereConditions()<br/>reads where.selector_in
Resolver->>DB: SELECT ... FROM events WHERE selector IN (...)
Note over DB: events.selector column<br/>(was topic0) + bySelector index
DB-->>Resolver: event rows
Resolver-->>Client: paginated EventConnection
Last reviewed commit: f39f7df |
There was a problem hiding this comment.
Pull request overview
Renames the ENSv2 event “topic0” field to “selector” across the shared schema, indexer write-path, and ENSApi GraphQL filter inputs, aligning naming with the semantic meaning of the first log topic (event signature/selector).
Changes:
- Renamed
events.topic0→events.selectorin the ENSv2 onchain schema (andbyTopic0→bySelectorindex). - Renamed GraphQL filter input
topic0_in→selector_inand updated resolver filtering logic. - Updated the pending changeset description to reference
selector_in.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| packages/ensnode-schema/src/schemas/ensv2.schema.ts | Renames the persisted events column and its index. |
| apps/ensindexer/src/lib/ensv2/event-db-helpers.ts | Writes selector instead of topic0 when persisting events. |
| apps/ensapi/src/graphql-api/schema/event.ts | Renames the public GraphQL filter field to selector_in (and updates descriptions). |
| apps/ensapi/src/graphql-api/lib/find-events/find-events-resolver.ts | Updates SQL filtering to use schema.event.selector and the new selector_in key. |
| .changeset/shy-wolves-judge.md | Updates release-note text to mention selector_in. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
You can also share your feedback on Copilot code review. Take the survey.
| address: t.hex().notNull().$type<Address>(), | ||
| logIndex: t.integer().notNull().$type<number>(), | ||
| topic0: t.hex().notNull().$type<Hash>(), | ||
| selector: t.hex().notNull().$type<Hash>(), | ||
| topics: t.hex().array().notNull().$type<[Hash, ...Hash[]]>(), | ||
| data: t.hex().notNull(), | ||
| }), | ||
| (t) => ({ | ||
| byTopic0: index().on(t.topic0), | ||
| bySelector: index().on(t.selector), | ||
| byFrom: index().on(t.from), |
There was a problem hiding this comment.
Renaming the persisted events table column from topic0 to selector (and index rename) will break existing Postgres/Ponder databases that already have topic0 (queries/inserts will fail unless the DB is rebuilt or migrated). Please add an explicit migration/upgrade path (e.g., SQL ALTER TABLE ... RENAME COLUMN, index rename) or clearly document that a full re-index / DB reset is required for this change.
| selector_in: t.field({ | ||
| type: ["Hex"], | ||
| description: "Filter to events whose topic0 (event signature) is one of the provided values.", | ||
| description: | ||
| "Filter to events whose selector (event signature) is one of the provided values.", | ||
| }), |
There was a problem hiding this comment.
This removes the topic0_in input field and replaces it with selector_in. If topic0_in has been part of any released/used GraphQL schema, this is a breaking API change for clients. Consider keeping topic0_in as a deprecated alias (with a deprecation reason pointing to selector_in) for at least one release cycle, or otherwise document the breaking change prominently.
| function eventsWhereConditions(where?: EventsWhere | null): SQL | undefined { | ||
| if (!where) return undefined; | ||
|
|
||
| return and( | ||
| where.topic0_in | ||
| ? where.topic0_in.length | ||
| ? inArray(schema.event.topic0, where.topic0_in) | ||
| where.selector_in | ||
| ? where.selector_in.length | ||
| ? inArray(schema.event.selector, where.selector_in) | ||
| : sql`false` | ||
| : undefined, |
There was a problem hiding this comment.
There are integration tests for events pagination, but none appear to cover the where.selector_in filter path. Since this PR renames a public filter field and changes the SQL condition to use schema.event.selector, it would be easy for a regression to slip through without a targeted test. Please add at least one integration test that queries a connection with where: { selector_in: [...] } and asserts results are filtered correctly.
Summary
topic0column toselectorin the ensv2 event schema (including DB indexbyTopic0→bySelector)topic0_infilter toselector_inin all GraphQLEventsWhereInput/AccountEventsWhereInputtypes and the underlying resolver logicWhy
selectormore accurately describes what topic0 represents (the event signature / selector), aligning the API terminology with its semantic meaningTesting
pnpm typecheck— all packages passpnpm lint— cleanChecklist
Closes #1759
🤖 Generated with Claude Code