Currently, an ENSIndexer instance has a dependency on the related ENSRainbow instace, such that until the ENSRainbow instance is ready to serve HTTP traffic, the ENSIndexer instance:
- Cannot start indexing onchain data.
- Cannot determine the
EnsIndexerPublicConfig object, which prevents ENSDb Writer Worker from writing EnsIndexerPublicConfig record to ENSDb, and as a result, crashes the ENSIndexer instance.
In a cold-start scenario, it might take more than 30 minutes for the ENSRainbow instance to reach the readiness and open its HTTP server.
While the 1st issue remains unadressed, we can and should address the 2nd isssue.
We could make the ensRainbowPublicConfig field on EnsIndexerPublicConfig data model optional. By doing so, the ENSIndexer instance will be able to determine the EnsIndexerPublicConfig object even during the ENSRainbow instance cold-start period. Having EnsIndexerPublicConfig object, ENSDb Writer Worker will be able to populate ENSDb with ENSNode Meetadata (including ENSIndexer Public Config, and Indexing Status where all chains in queued status).
Key points to reflect on while designing the solution for this issue:
- The deeper goal here is we want to make it so that the startup dependencies across our services are softened to improve the experience of operators launching services.
- Fetching the
EnsRainbowPublicConfig object will require multiple retries. Once the config object was fetched successfully, it should remain cached indefinitely.
- When
EnsRainbowPublicConfig object becomes available in the cache, the ENSDb Writer Worker should update the ENSIndexer Public Config record in ENSNode Metadata table to and update its ensRainbowPublicConfig column from undefined to the cached EnsRainbowPublicConfig object.
- Changing the type of
EnsIndexerPublicConfig['ensRainbowPublicConfig'] field from EnsIndexerPublicConfig to EnsIndexerPublicConfig | underfined will create side effects on EnsIndexerPublicConfig data model consumers, for example, ENSApi, ENSAdmin. Please make sure to take that into consideration while designing the updates for this issue.
Currently, an ENSIndexer instance has a dependency on the related ENSRainbow instace, such that until the ENSRainbow instance is ready to serve HTTP traffic, the ENSIndexer instance:
EnsIndexerPublicConfigobject, which prevents ENSDb Writer Worker from writingEnsIndexerPublicConfigrecord to ENSDb, and as a result, crashes the ENSIndexer instance.In a cold-start scenario, it might take more than 30 minutes for the ENSRainbow instance to reach the readiness and open its HTTP server.
While the 1st issue remains unadressed, we can and should address the 2nd isssue.
We could make the
ensRainbowPublicConfigfield onEnsIndexerPublicConfigdata model optional. By doing so, the ENSIndexer instance will be able to determine theEnsIndexerPublicConfigobject even during the ENSRainbow instance cold-start period. HavingEnsIndexerPublicConfigobject, ENSDb Writer Worker will be able to populate ENSDb with ENSNode Meetadata (including ENSIndexer Public Config, and Indexing Status where all chains in queued status).Key points to reflect on while designing the solution for this issue:
EnsRainbowPublicConfigobject will require multiple retries. Once the config object was fetched successfully, it should remain cached indefinitely.EnsRainbowPublicConfigobject becomes available in the cache, the ENSDb Writer Worker should update the ENSIndexer Public Config record in ENSNode Metadata table to and update itsensRainbowPublicConfigcolumn fromundefinedto the cachedEnsRainbowPublicConfigobject.EnsIndexerPublicConfig['ensRainbowPublicConfig']field fromEnsIndexerPublicConfigtoEnsIndexerPublicConfig | underfinedwill create side effects onEnsIndexerPublicConfigdata model consumers, for example, ENSApi, ENSAdmin. Please make sure to take that into consideration while designing the updates for this issue.