Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specify catch up block height in config #105

Closed
cam-schultz opened this issue Dec 11, 2023 · 1 comment
Closed

Specify catch up block height in config #105

cam-schultz opened this issue Dec 11, 2023 · 1 comment
Assignees
Labels
enhancement New feature or request

Comments

@cam-schultz
Copy link
Collaborator

cam-schultz commented Dec 11, 2023

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:

  1. 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
  1. 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
  1. 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.

@cam-schultz cam-schultz added the enhancement New feature or request label Dec 11, 2023
@cam-schultz cam-schultz self-assigned this Dec 14, 2023
@cam-schultz cam-schultz moved this from Backlog 🗄️ to In Progress 🏗 in Platform Engineering Group Dec 14, 2023
@cam-schultz cam-schultz moved this from In Progress 🏗 to In Review 👀 in Platform Engineering Group Jan 3, 2024
@cam-schultz
Copy link
Collaborator Author

Fixed by #133

@github-project-automation github-project-automation bot moved this from In Review 👀 to Done ✅ in Platform Engineering Group Jan 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

1 participant