multi network ENS resolver

[pk910]

No description provided.

[redpandabot]

Summary

Multi-network ENS resolver rework: names are now resolved on the local chain plus optional remote networks (persisted per (address,network)), a new ENS forward-search path, a schema migration, and CDN cache-busting for static assets. The design is solid and I found no blockers, but there are two operational concerns: a perpetual re-enqueue loop when a remote network endpoint stays down, and a silent removal of the old top-level ensResolver.endpoints config key.

Issues

• 🟡 services/ensresolver.go:724 — permanently-failing network keeps every viewed address in an endless re-resolve loop — see the thread on that line
• 🟡 types/config.go:221 — top-level ensResolver.endpoints silently removed — existing configs lose their ENS target — The old EnsResolver.Endpoints field (used to point the resolver at a dedicated mainnet RPC, the only way to show mainnet ENS from a non-mainnet explorer) is deleted with no migration or warning; yaml.Unmarshal silently ignores the stale key. After upgrade such deployments resolve against the indexed chain's own execution pool and ENS stops resolving until they migrate to remoteNetworks. Worth a release note / deprecation shim (e.g. map old endpoints into a synthetic remote network).

---

_{Reviewed @ d5e933fd
"Documentation is a love letter you write to your future self." — Damian Conway}

[redpandabot]

Summary

This PR reworks the ENS resolver into a multi-network service: per-(address,network) persistence with a composite PK migration, probe-based registry discovery with backoff, per-network staleness so addresses settle while an endpoint is down, forward resolution for search, a client-side callout, and a cache-busting assetVersion helper. The core resolve/persist/refresh logic is coherent and well-tested; I found one mismatch between the documented failure handling and what the code actually persists, plus a small search-regex gap.

Issues

• 🟡 services/ensresolver.go:834 — transient ENS call errors are persisted as negative results instead of triggering backoff — resolveWithRegistry/resolveForward swallow callBatch errors (ensresolver_ens.go:161/197/226/254 and :92/105) and return an empty map, so resolveBatchOnNetwork returns nil error and processBatch marks the network available (ensresolver.go:772) and inserts Name:'' rows for the whole batch. A short RPC hiccup or the global 60s batch deadline therefore stores false negatives that are not retried until RefreshNegative (6h), contradicting the processBatch comment that networks failing with a client error get no persisted result; the individual-call path (ensresolver_ens.go:286) also swallows per-call errors as "no name".
• 🟢 handlers/search.go:33 — ENS search regex excludes 2-char TLDs such as cb.id — ensNameRE requires the final label to be >=3 chars, so complete names like username.cb.id (Coinbase's ENS TLD) never match and are never forward-resolved/redirected by the search; they can still surface via prefix suggestions only if already reverse-resolved.

---

_{Reviewed @ c7d32a6e
"Documentation is a love letter you write to your future self." — Damian Conway}