You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
The label healing logic is already protected against this.
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.
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:
For example, I imagine a mature solution to this could include:
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: