-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Mempool sorting and accept reverted pending transactions #3683
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see how a test is covering the mempool ordering
@@ -96,11 +96,11 @@ async def create_bundle_from_mempool( | |||
additions = [] | |||
broke_from_inner_loop = False | |||
log.info(f"Starting to make block, max cost: {self.constants.MAX_BLOCK_COST_CLVM}") | |||
for dic in self.mempool.sorted_spends.values(): | |||
for dic in reversed(self.mempool.sorted_spends.values()): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does it still make sense to keep sorted_spends
sorted the other way? I imagine future mistake similar to this one, assuming this list is sorted the way one would expect
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We do want to check them in increasing order when booting things out of the mempool.
successful_bundle, successful_bundle.name(), peer, test=True | ||
) | ||
assert status == MempoolInclusionStatus.FAILED | ||
assert err == Err.ALREADY_INCLUDING_TRANSACTION |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand this. How is force_high_fee
related to this response to the peer?
Sending a response to a peer here seems new too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The force_high_fee means that that transaction is guaranteed to go into the block that we make. Th way we know that it goes is, is first we try to submit the transaction again, but it will fail because it's already in the mempool.
Then, after making the block, we submit the transaction again, and we will not get ALREADY_INCLUDING_TRANSACTION, we will get a different error. This is because when updating the mempool for the block, we remove traces of old transactions from the seen map.
This is necessary, because when we do a reorg (reverting tx block) we want to be able top resubmit, which we also test
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. I hadn't realized this was a test when reviewing this. This makes sense now.
* 2 harvesting features (#3331) * 3 harvesting features: - Debug level shows the time for every quality lookup - Warning level if takes longer than 5 seconds - Allow configuration of plot loading interval (default 2 minutes) * Comment out super logging * Improve wallet consistency (#3305) * Improve wallet consistency * Improve CLI significantly, and fix self-tx balances * Fix await * Fix deadlock and test * Remove spam.sh * Changelog for 1.1.3 (#3345) * Changelog for 1.1.3 * minor updates * updates part 3 * Those engineers who don't update changelogs... :) * Apologies to @Chida82 who added log rotate count! (#3369) * Rust parse serialized (#3444) * use rust implementation for finding length of a serialized clvm program * bump clvm_rs version * Don't retry respond_peers message (#3508) * don't increment counters for outgoing messages blocked by the rate limit. (#3518) This was causing a problem where outbound messages, blocked by the rate limiter, would still increment the counters as-if they had been sent. This, in turn, could cause other message types to get blocked becuase the rate limiter thought we had sent a lot of the other (blocked) message type. * hide secret wallet key by default with 'chia keys show' (#3565) Co-authored-by: Adam Kelly <aqk@aqk.im> * brake if end of ses list (#3583) * brake if end of ses list * log * throw if wp peak is not heavier * comment * handle sync from scratch * comment * fix indentation issue in message send retry logic. factor out retry coroutine (#3629) * Fix test (#3350) * Mempool sorting and accept reverted pending transactions (#3683) * Sort by fee/cost, and fix pending tx issue in reorgs * Fix test name * Bring the seen list size back to normal. Co-authored-by: Mariano Sorgente <3069354+mariano54@users.noreply.github.com> Co-authored-by: Gene Hoffman <30377676+hoffmang9@users.noreply.github.com> Co-authored-by: Arvid Norberg <arvid@libtorrent.org> Co-authored-by: Adam Kelly <338792+aqk@users.noreply.github.com> Co-authored-by: Adam Kelly <aqk@aqk.im> Co-authored-by: Almog De Paz <almogdepaz@gmail.com>
No description provided.