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:
- 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: