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

Significant state about forks is stored in ephemeral blockHistory #123

Open
flux627 opened this issue Feb 15, 2019 · 3 comments
Open

Significant state about forks is stored in ephemeral blockHistory #123

flux627 opened this issue Feb 15, 2019 · 3 comments

Comments

@flux627
Copy link
Contributor

flux627 commented Feb 15, 2019

Rollbacks can only be initiated when the action reader sees them happening, with its occurrence stored in AbstractActionReader#blockHistory. If the indexState is on a forked block at startup, then the action reader will not have any way of knowing this and send a block whose blockHash does not match, and it is not trivial to determine how far the Handler needs to roll back.

@jeffreyssmith2nd
Copy link
Contributor

It's been awhile since we discussed it, but we talked at one point about persisting blockHistory to Postgres. Would that be one potential solution here?

@flux627
Copy link
Contributor Author

flux627 commented Feb 20, 2019

blockHistory is something that's in the ActionReader. Maybe we could make a abstract subclass of the AbstractActionReader called the AbstractPostgresActionReader or something, that connects to a postgres database for persisting its own state, but I think a cleaner solution would be to:

  • Persist lastIrreversibleBlock data to indexState
  • Detect this case when the ActionHandler processes its first block, and rolls back to the lastIrreversibleBlock number from indexState
  • Request the next block needed after the ActionHandler's rollback

@jeffreyssmith2nd
Copy link
Contributor

Step 1 will be done in #132

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants