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
I want to index a list of contracts that is stored offchain (e.g. the factory pattern doesn't work). Specifically, I want to be able to add to this list of contracts without restarting the server, just like how factory contracts work.
I want to index a large number of chains in the same way (configuration stored off-chain).
Possible solution
Add a dynamic address function, similar to factory, which polls an external HTTP endpoint to fetch the list of addresses. When the list changes, the indexer fetches & syncs the new contract accordingly.
The complexity here is that if the app's indexing logic for the contract is not "isolated" (such that events across all addresses must be indexed in EVM execution order to achieve the correct database state) you'll end up with an inconsistent/non-deterministic database state. One way to solve this would be to treat every config update the same way we handle a reorg (revert all indexing back to the new contract's start block) but I don't think that's what folks are looking for.
The text was updated successfully, but these errors were encountered:
Requirement / story
I want to index a list of contracts that is stored offchain (e.g. the
factory
pattern doesn't work). Specifically, I want to be able to add to this list of contracts without restarting the server, just like howfactory
contracts work.I want to index a large number of chains in the same way (configuration stored off-chain).
Possible solution
Add a dynamic address function, similar to
factory
, which polls an external HTTP endpoint to fetch the list of addresses. When the list changes, the indexer fetches & syncs the new contract accordingly.The complexity here is that if the app's indexing logic for the contract is not "isolated" (such that events across all addresses must be indexed in EVM execution order to achieve the correct database state) you'll end up with an inconsistent/non-deterministic database state. One way to solve this would be to treat every config update the same way we handle a reorg (revert all indexing back to the new contract's start block) but I don't think that's what folks are looking for.
The text was updated successfully, but these errors were encountered: