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
Context and scope
The catch up mechanism reads from the JSON database to get the starting block from which to begin processing. This starting block is set automatically by the relayer as blocks are processed during runtime. There's no easy way for the user to specify the starting block; we should add a config option to do so.
Open questions
Should we limit the range of blocks that we process in one go? We don't currently do this in the automated approach, but this assumes a finite range since it's based on relayer downtime. Here, the user can specify an arbitrarily large range.
How should we "clean up" the config once we've already processed from the configured height? One idea would be to only process from the maximum of the configured block height and the stored block height, and then store the block height whenever we process a block (which we already do). The behavior in the following scenarios would be:
No block height is stored in the DB, configured block height is 100, and the current block height is 1000
We'd process blocks 100-1000 on startup, and store 1000 in the DB
Block height of 99 is stored in the DB, configured block height is 100, and the current block height is 1000
We'd process blocks 100-1000 on startup, and store 1000 in the DB
Block height of 101 is stored in the DB, configured block height is 100, and the current block height is 1000
We'd process blocks 101-1000 on startup, and store 1000 in the DB
All the above scenarios would be equavalent to scenario 3 after initialization & restart.
The text was updated successfully, but these errors were encountered:
Context and scope
The catch up mechanism reads from the JSON database to get the starting block from which to begin processing. This starting block is set automatically by the relayer as blocks are processed during runtime. There's no easy way for the user to specify the starting block; we should add a config option to do so.
Open questions
Should we limit the range of blocks that we process in one go? We don't currently do this in the automated approach, but this assumes a finite range since it's based on relayer downtime. Here, the user can specify an arbitrarily large range.
How should we "clean up" the config once we've already processed from the configured height? One idea would be to only process from the maximum of the configured block height and the stored block height, and then store the block height whenever we process a block (which we already do). The behavior in the following scenarios would be:
All the above scenarios would be equavalent to scenario 3 after initialization & restart.
The text was updated successfully, but these errors were encountered: