Sub-issue of #2035.
Context
The apps/manager migration flow (PR ensdomains/apps-monorepo#593) needs to fetch just the V1 names an Account owns — the entire migration UI is "pick which V1 names to upgrade to V2." Today this is a direct V1-subgraph fetch (getV1NamesForAddress in apps/manager/src/features/migration/service/v1SubgraphClient.ts) returning ENSv1Domains with wrappedDomain.fuses, parent, registrant, wrappedOwner, resolver.address, etc.
In Omnigraph, account(by: { address }) { domains { ... } } returns both ENSv1Domains and ENSv2Domains in the same connection. To filter to V1-only the client must inspect __typename after fetching — wasteful when the user has many V2 names too, and impossible to combine with server-side where/order semantics.
Proposed
Add a protocol-version filter to the find-domains-shaped queries:
where: { version: V1 } # or V2Applies to (at least):
Account.domains(where: AccountDomainsWhereInput)Query.domains(where: DomainsWhereInput!)Registry.domains(where: RegistryDomainsWhereInput) (if meaningful — virtual registries straddle versions)Domain.subdomains(where: SubdomainsWhereInput) (likely not needed but for consistency)
Exact shape TBD — could be a scalar enum (version: ENSVersion), a __typename-style filter (typename_in: [\"ENSv1Domain\", \"ENSv2Domain\"]), or a structural `{ v1: true }` flag. Naming and union semantics need a design pass.
Canonicality / name field gotcha
After ENSv2 is deployed, ENSv1Domains are no longer canonical, and Domain.name is documented as null when the domain is not canonical ("The Canonical Name for this Domain. If the Domain is not Canonical, then `name` will be null"). That means a query like `account.domains(where: { version: V1 }) { name }` would return all-null names today — useless to the migration UI.
We need either:
- Update
Domain.name semantics so ENSv1Domains expose a name regardless of canonicality (it's still a perfectly meaningful name in the V1 namegraph, just not in the unified canonical one). The schema doc on `name` would need to reflect this. Or:
- Add a separate `legacyName` / `v1Name` field that always carries the V1-namegraph name.
Option 1 is cleaner; option 2 avoids changing existing semantics.
Materialization dependency
This filter (and the version-aware name surfacing) likely depends on materialization of the canonical namegraph end-to-end so that V1 vs V2 set membership can be answered server-side without per-row indirection. Same dependency family as #1962, #2059.
Why this matters
Without it, manager either:
- keeps hitting the V1 subgraph directly (defeating the point of unifying on Omnigraph), or
- pulls a user's full domain list through Omnigraph and filters client-side — wasteful and the names are null anyway under current canonicality rules.
Related
Sub-issue of #2035.
Context
The
apps/managermigration flow (PR ensdomains/apps-monorepo#593) needs to fetch just the V1 names an Account owns — the entire migration UI is "pick which V1 names to upgrade to V2." Today this is a direct V1-subgraph fetch (getV1NamesForAddressinapps/manager/src/features/migration/service/v1SubgraphClient.ts) returning ENSv1Domains withwrappedDomain.fuses,parent,registrant,wrappedOwner,resolver.address, etc.In Omnigraph,
account(by: { address }) { domains { ... } }returns both ENSv1Domains and ENSv2Domains in the same connection. To filter to V1-only the client must inspect__typenameafter fetching — wasteful when the user has many V2 names too, and impossible to combine with server-sidewhere/ordersemantics.Proposed
Add a protocol-version filter to the find-domains-shaped queries:
Applies to (at least):
Account.domains(where: AccountDomainsWhereInput)Query.domains(where: DomainsWhereInput!)Registry.domains(where: RegistryDomainsWhereInput)(if meaningful — virtual registries straddle versions)Domain.subdomains(where: SubdomainsWhereInput)(likely not needed but for consistency)Exact shape TBD — could be a scalar enum (
version: ENSVersion), a__typename-style filter (typename_in: [\"ENSv1Domain\", \"ENSv2Domain\"]), or a structural `{ v1: true }` flag. Naming and union semantics need a design pass.Canonicality /
namefield gotchaAfter ENSv2 is deployed, ENSv1Domains are no longer canonical, and
Domain.nameis documented as null when the domain is not canonical ("The Canonical Name for this Domain. If the Domain is not Canonical, then `name` will be null"). That means a query like `account.domains(where: { version: V1 }) { name }` would return all-null names today — useless to the migration UI.We need either:
Domain.namesemantics so ENSv1Domains expose a name regardless of canonicality (it's still a perfectly meaningful name in the V1 namegraph, just not in the unified canonical one). The schema doc on `name` would need to reflect this. Or:Option 1 is cleaner; option 2 avoids changing existing semantics.
Materialization dependency
This filter (and the version-aware name surfacing) likely depends on materialization of the canonical namegraph end-to-end so that V1 vs V2 set membership can be answered server-side without per-row indirection. Same dependency family as #1962, #2059.
Why this matters
Without it, manager either:
Related