Skip to content
This repository was archived by the owner on Aug 5, 2026. It is now read-only.
This repository was archived by the owner on Aug 5, 2026. It is now read-only.

Cascading SWRCaches for stack info refresh #2062

Description

@lightwalker-eth

See related discussion in Slack here: https://namehash.slack.com/archives/C086Z6FNBHN/p1778014729212909

Current idea to handle this in a mature way is for us to relax the constraint that each of the following are immutable for the lifetime of a process instance lifecycle once loaded:

  • ENSIndexer's understanding of ENSRainbow's stack info
  • ENSApi's understanding of ENSIndexer's stack info

For example, I imagine a mature solution to this could include:

  • Transition each of the ideas listed above from being immutable once loaded, to being a SWR cache.
  • Each time the SWR cache already has state X loaded and then refreshes it upon receiving a new value Y, logic should ensure no invariants are being broken by the new value Y. For example, that ENSRainbow hasn't changed from one label set id to another.

A nice benefit of this is that if someone running their own ENSNode instance does something creative where they significantly reconfigure their ENSRainbow mid-indexing process:

  1. The label healing logic is already protected against this.
  2. The next time the SWRCache inside ENSIndexer fetches the stack info from ENSRainbow it will identify the incompatibility at a deeper level and therefore might provide more helpful error info to the ENSNode operator / purposefully terminate itself.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Projects

  • Status
    No status

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions