fatxpool: report_invalid: do not ban Future/Stale txs from re-entering the view
#7777
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
michalkucharczyk
changed the title
fatxpool: report_invalid: do not ban Future/Stale txs from re-entring the viewfatxpool: report_invalid: do not ban Future/Stale txs from re-entering the view
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.
Description
...tdb...
Note for reviewers
When re-org is handled by transaction pool, the view for new fork (
Bn') is cloned from the tip of the other existing fork (Bn). The new view is not entirely re-validated during the maintain process (it will be revalidated in the background), so it may happen that it contains transactions that are ready on (Bn) but actually are not ready on (Bn'). All required (which are expected to be in retracted set) transactions are submitted to the new view, but order of txs in ready iterator is not updated.The proper fix would require to re-build the the iterator - which is not trivial as we do not have tags for transactions for block
Bn'yet. We could force retracted txs to be before ready transactions but it also does not feel to be a good solution - it still would be best effort trial.For now allowing future transactions to re-enter the view immediately is in my opinion a good compromise. This PR is a quick fix and actually brings back behavior of txpool from before merging #6008. The bad thing is that incorrect transactions are detected during block authorship, but this situation to happen requires some specific pre-conditions which should be rare.
If this PR is not merged, some transaction will get included into blocks, only after
DEFAULT_BAN_TIME_SECS, which is pretty bad.