feat(block-producer): inflight state custody of transaction data #534
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Mirko-von-Leipzig
force-pushed
the
mirko-inflight-state-owns-data
branch
2 times, most recently
from
df42fe0 to
1bbc175
Compare
bobbinth
approved these changes
Nov 1, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR upgrades
InflightStateso that it tracks each transaction's state delta internally. We differentiate between committed and uncommitted transactions. The former cannot be reverted.This means reverting or committing transactions now only requires passing in the transaction IDs, instead of requiring the full transaction data.
This enables making the inflight state more robust as it now differentiates between committed and uncommitted transaction IDs. Additional work is required to change the current panics into errors instead, though this is left to a future PR as it isn't high priority. Tracked in #537.
Essentially this works towards hardening the different components of the mempool individually so that we can pick up corruption/bugs as soon as possible.