perf: Make mempool update async from block.Commit #3008

ValarDragon · 2024-05-06T00:34:19Z

First step to fixing #2925

PR'ing this to see if we have any test failures. Note that this is safe in the happy path, as Reap and CheckTx both share this same lock. The functionality behavior is that:

Full nodes and non-proposers timeout_prevote beginning should not block on updating the mempool
Block proposers get very slight increased concurrency before reaping their next block. (Should be significantly fixed in subsequent PR's in Mempool Rechecking all txs blocks consensus #2925)
- Reap takes a lock on the mempool mutex, so there is no concurrency safety issues right now.
Mempool errors will not halt consensus, instead they just log an error and call mempool flush. I actually think this may be better behavior? If we want to preserve the old behavior, we can thread a generic "consensus halt error" channel perhaps?

I'm not sure how/where to best document this. Please also let me know if tests need creating. Seems like the create empty block tests sometimes hit failures, I'll investigate tmrw

Also please feel free to take over this PR, just thought I"d make it to help us with performance improvements. Happy to get this into an experimental release to test on mainnets.

PR checklist

Tests written/updated
Changelog entry added in .changelog (we use unclog to manage our changelog)
Updated relevant documentation (docs/ or spec/) and code comments
Title follows the Conventional Commits spec

melekes · 2024-05-06T10:01:50Z

state/execution.go

-	return res.RetainHeight, err
+	if err != nil {
+		blockExec.logger.Error("client error during mempool.Update, flushing mempool", "err", err)
+		blockExec.mempool.Flush()


This is new, right? Why it's important to flush the mempool?

Before we would halt, sorry forgot to flag in a comment. I feel like we only have two options, dump the mempool or replicate existing functionality and make an error channel to halt consensus

Any caller of function Commit in line 395 above will panic if Commit doesn't return a nil error. This is for safety and has been like that for years. I'd feel more comfortable if we didn't modify that behavior here, so if err != nil in line 445, I'd panic here with the error text of line 446.

Sounds good!

cason · 2024-05-10T13:44:54Z

Full nodes and non-proposers timeout_prevote beginning should not block on updating the mempool

What do you mean? In any case, it is probably timeout_commit.

cason · 2024-05-10T13:50:08Z

One problem of this approach is that this breaks the contract that we have regarding the ABCI Commit method:

https://docs.cometbft.com/v0.38/spec/abci/abci++_app_requirements#commit

Before invoking Commit, CometBFT locks the mempool and flushes the mempool connection. This ensures that no new messages will be received on the mempool connection during this processing step, providing an opportunity to safely update all four connection states to the latest committed state at the same time.

When Commit returns, CometBFT unlocks the mempool.

By updating the mempool in parallel, this contract is clearly broken.

cason

I would prefer to block this change while we address how we are handling the contract with the application as part of the ABCI Commit call.

state/execution.go

cason · 2024-05-10T13:55:11Z

state/execution.go

+	if updateData.err != nil {
+		return
+	}
+
 	err = blockExec.mempool.Update(


This part we can do in parallel.

Once the new state is committed, the application can start performing the re-check of all transactions remaining in the mempool, using the updated state.

Moreover, it is not clear to me why we need to call Update with a locked mempool...

As far as I understand, this is due to the current FIFO guarantee, before you add a new tx. (You want to know your done rechecking, before you add more txs to the end)

This really should be a lock owned within the mempool though, rather than here.

ValarDragon · 2024-05-13T21:30:44Z

One problem of this approach is that this breaks the contract that we have regarding the ABCI Commit method:

https://docs.cometbft.com/v0.38/spec/abci/abci++_app_requirements#commit

Before invoking Commit, CometBFT locks the mempool and flushes the mempool connection. This ensures that no new messages will be received on the mempool connection during this processing step, providing an opportunity to safely update all four connection states to the latest committed state at the same time.
When Commit returns, CometBFT unlocks the mempool.

By updating the mempool in parallel, this contract is clearly broken.

After your fix of flushing the mempool before Commit, we are only breaking the contract in "When Commit returns, CometBFT unlocks the mempool.". We do flush and take a lock during Commit. We just now hold the lock after Commit terminates. I'm not sure that application behavior would depend on this.

ValarDragon · 2024-05-14T05:04:48Z

I'm still stuck on the create empty blocks tests. Going to try more tomorrow. But somehow playing around with the timeouts / expanding leniency isn't fixing this. (Testing via running go test -timeout 30s -run ^TestMempoolProgressAfterCreateEmptyBlocksInterval$ github.com/cometbft/cometbft/internal/consensus -count=100 -p=1)

Apriori I'd just guess maybe we shaved 10ms or something in this configuration in edge cases. Going to try more with a debugger tmrw.

melekes · 2024-05-14T08:11:08Z

@hvanz could you please help @ValarDragon here?

hvanz

Looks good. I've also run the tests and they all pass.

Regarding the ABCI spec on Commit, I don't think this change will pose a problem. The important part of that paragraph is "Before invoking Commit, CometBFT locks the mempool and flushes the mempool connection.". This is not broken.

But the line "When Commit returns, CometBFT unlocks the mempool." should be updated to reflect the new behaviour. I think it doesn't matter for the ABCI connections that the mempool is still locked after Commit returns.

state/execution.go

ValarDragon · 2024-05-17T09:18:30Z

I think the failing test cases is due to some race condition bug in the timeout ticker relating to ticks with negative durations.

I added some logs, and in the passing cases I see logs like:

Received tick old_ti {40ms 1 0 RoundStepPropose} new_ti {-142.018µs 2 0 RoundStepNewHeight}
1715938581269 Scheduled timeout dur -142.018µs height 2 round 0 step RoundStepNewHeight
Received tick old_ti {-142.018µs 2 0 RoundStepNewHeight} new_ti {200ms 2 0 RoundStepNewRound}
1715938581269 Scheduled timeout dur 200ms height 2 round 0 step RoundStepNewRound
1715938581469 Timed out dur 200ms height 2 round 0 step RoundStepNewRound
1715938581469 handle timeout, timeout type {200ms 2 0 RoundStepNewRound}

where the left number is time.Now().UnixMilli()

In the failing test cases I see:

Received tick old_ti {40ms 1 0 RoundStepPropose} new_ti {-161.505µs 2 0 RoundStepNewHeight}
1715938583735 Scheduled timeout dur -161.505µs height 2 round 0 step RoundStepNewHeight
Received tick old_ti {-161.505µs 2 0 RoundStepNewHeight} new_ti {200ms 2 0 RoundStepNewRound}
Timer already stopped
1715938583735 Scheduled timeout dur 200ms height 2 round 0 step RoundStepNewRound

(So were not getting the 200ms wait)

Trying to figure out whats the cause of this edge case. I think this has to be independent of my change though.

ValarDragon · 2024-05-17T09:46:43Z

Ok just confirmed I get this same failure on main when I run the test in a loop, so its not new to this PR (and is an edge case failure in the timeout ticker)

Going to file this into an issue, and consider the test failure here in this PR (vs not main) as a fluke. Will try to fix that separately in another PR.

EDIT: Filed into issue / PR, #3091 / #3092 . I think that should not block this PR, as this behavior exists in the same manner. Or perhaps we merge that in first, then rebase into this PR?

sergio-mena · 2024-05-22T12:51:12Z

Or perhaps we merge that in first, then rebase into this PR?

I favour that approach

.changelog/unreleased/features/3008-mempool-async-update.md

sergio-mena · 2024-05-22T12:59:17Z

state/execution.go

+	state        State
+	abciResponse *abci.FinalizeBlockResponse
+}
+
 // Commit locks the mempool, runs the ABCI Commit message, and updates the


Do we need to update this comment?

Co-authored-by: Sergio Mena <sergio@informal.systems>

state/execution.go

First step to fixing cometbft#2925 PR'ing this to see if we have any test failures. Note that this is safe in the happy path, as Reap and CheckTx both share this same lock. The functionality behavior is that: - Full nodes and non-proposers `timeout_prevote` beginning should not block on updating the mempool - Block proposers get _very slight_ increased concurrency before reaping their next block. (Should be significantly fixed in subsequent PR's in - Reap takes a lock on the mempool mutex, so there is no concurrency safety issues right now. - Mempool errors will not halt consensus, instead they just log an error and call mempool flush. I actually think this may be better behavior? If we want to preserve the old behavior, we can thread a generic "consensus halt error" channel perhaps? I'm not sure how/where to best document this. Please also let me know if tests need creating. Seems like the create empty block tests sometimes hit failures, I'll investigate tmrw Also please feel free to take over this PR, just thought I"d make it to help us with performance improvements. Happy to get this into an experimental release to test on mainnets. --- - [ ] Tests written/updated - [x] Changelog entry added in `.changelog` (we use [unclog](https://github.com/informalsystems/unclog) to manage our changelog) - [ ] Updated relevant documentation (`docs/` or `spec/`) and code comments - [x] Title follows the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) spec --------- Co-authored-by: Sergio Mena <sergio@informal.systems>

First step to fixing cometbft#2925 PR'ing this to see if we have any test failures. Note that this is safe in the happy path, as Reap and CheckTx both share this same lock. The functionality behavior is that: - Full nodes and non-proposers `timeout_prevote` beginning should not block on updating the mempool - Block proposers get _very slight_ increased concurrency before reaping their next block. (Should be significantly fixed in subsequent PR's in - Reap takes a lock on the mempool mutex, so there is no concurrency safety issues right now. - Mempool errors will not halt consensus, instead they just log an error and call mempool flush. I actually think this may be better behavior? If we want to preserve the old behavior, we can thread a generic "consensus halt error" channel perhaps? I'm not sure how/where to best document this. Please also let me know if tests need creating. Seems like the create empty block tests sometimes hit failures, I'll investigate tmrw Also please feel free to take over this PR, just thought I"d make it to help us with performance improvements. Happy to get this into an experimental release to test on mainnets. --- - [ ] Tests written/updated - [x] Changelog entry added in `.changelog` (we use [unclog](https://github.com/informalsystems/unclog) to manage our changelog) - [ ] Updated relevant documentation (`docs/` or `spec/`) and code comments - [x] Title follows the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) spec --------- Co-authored-by: Dev Ojha <ValarDragon@users.noreply.github.com> Co-authored-by: Sergio Mena <sergio@informal.systems>

First step to fixing cometbft#2925 PR'ing this to see if we have any test failures. Note that this is safe in the happy path, as Reap and CheckTx both share this same lock. The functionality behavior is that: - Full nodes and non-proposers `timeout_prevote` beginning should not block on updating the mempool - Block proposers get _very slight_ increased concurrency before reaping their next block. (Should be significantly fixed in subsequent PR's in - Reap takes a lock on the mempool mutex, so there is no concurrency safety issues right now. - Mempool errors will not halt consensus, instead they just log an error and call mempool flush. I actually think this may be better behavior? If we want to preserve the old behavior, we can thread a generic "consensus halt error" channel perhaps? I'm not sure how/where to best document this. Please also let me know if tests need creating. Seems like the create empty block tests sometimes hit failures, I'll investigate tmrw Also please feel free to take over this PR, just thought I"d make it to help us with performance improvements. Happy to get this into an experimental release to test on mainnets. --- - [ ] Tests written/updated - [x] Changelog entry added in `.changelog` (we use [unclog](https://github.com/informalsystems/unclog) to manage our changelog) - [ ] Updated relevant documentation (`docs/` or `spec/`) and code comments - [x] Title follows the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) spec --------- Co-authored-by: Dev Ojha <ValarDragon@users.noreply.github.com> Co-authored-by: Sergio Mena <sergio@informal.systems> (cherry picked from commit 2cea495)

… (#71) First step to fixing cometbft#2925 PR'ing this to see if we have any test failures. Note that this is safe in the happy path, as Reap and CheckTx both share this same lock. The functionality behavior is that: - Full nodes and non-proposers `timeout_prevote` beginning should not block on updating the mempool - Block proposers get _very slight_ increased concurrency before reaping their next block. (Should be significantly fixed in subsequent PR's in - Reap takes a lock on the mempool mutex, so there is no concurrency safety issues right now. - Mempool errors will not halt consensus, instead they just log an error and call mempool flush. I actually think this may be better behavior? If we want to preserve the old behavior, we can thread a generic "consensus halt error" channel perhaps? I'm not sure how/where to best document this. Please also let me know if tests need creating. Seems like the create empty block tests sometimes hit failures, I'll investigate tmrw Also please feel free to take over this PR, just thought I"d make it to help us with performance improvements. Happy to get this into an experimental release to test on mainnets. --- - [ ] Tests written/updated - [x] Changelog entry added in `.changelog` (we use [unclog](https://github.com/informalsystems/unclog) to manage our changelog) - [ ] Updated relevant documentation (`docs/` or `spec/`) and code comments - [x] Title follows the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) spec --------- Co-authored-by: Dev Ojha <ValarDragon@users.noreply.github.com> Co-authored-by: Sergio Mena <sergio@informal.systems> (cherry picked from commit 2cea495) Co-authored-by: PaddyMc <paddymchale@hotmail.com>

faddat · 2024-05-27T07:14:10Z

I just want to say that this actually, if it works how I think it will work, looks like it may be a very significant piece of solving the P2P storms puzzle.

First step to fixing cometbft#2925 PR'ing this to see if we have any test failures. Note that this is safe in the happy path, as Reap and CheckTx both share this same lock. The functionality behavior is that: - Full nodes and non-proposers `timeout_prevote` beginning should not block on updating the mempool - Block proposers get _very slight_ increased concurrency before reaping their next block. (Should be significantly fixed in subsequent PR's in - Reap takes a lock on the mempool mutex, so there is no concurrency safety issues right now. - Mempool errors will not halt consensus, instead they just log an error and call mempool flush. I actually think this may be better behavior? If we want to preserve the old behavior, we can thread a generic "consensus halt error" channel perhaps? I'm not sure how/where to best document this. Please also let me know if tests need creating. Seems like the create empty block tests sometimes hit failures, I'll investigate tmrw Also please feel free to take over this PR, just thought I"d make it to help us with performance improvements. Happy to get this into an experimental release to test on mainnets. --- - [ ] Tests written/updated - [x] Changelog entry added in `.changelog` (we use [unclog](https://github.com/informalsystems/unclog) to manage our changelog) - [ ] Updated relevant documentation (`docs/` or `spec/`) and code comments - [x] Title follows the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) spec --------- Co-authored-by: Sergio Mena <sergio@informal.systems>

From cometbft#3008

sergio-mena · 2024-06-28T12:03:41Z

An update regarding this.

We have finally decided to backport this to v1.x because:

Our e2e nightlies are failing, and that is blocking our process for cutting v1.x RC. We are convinced this is part of the fix for those failing tests. So I added the "bug" label
@ValarDragon reported that this fix has been in production on Osmosis for a few weeks now without issue.

So, benefits clearly outweigh the risks at this point.

First step to fixing #2925 PR'ing this to see if we have any test failures. Note that this is safe in the happy path, as Reap and CheckTx both share this same lock. The functionality behavior is that: - Full nodes and non-proposers `timeout_prevote` beginning should not block on updating the mempool - Block proposers get _very slight_ increased concurrency before reaping their next block. (Should be significantly fixed in subsequent PR's in #2925) - Reap takes a lock on the mempool mutex, so there is no concurrency safety issues right now. - Mempool errors will not halt consensus, instead they just log an error and call mempool flush. I actually think this may be better behavior? If we want to preserve the old behavior, we can thread a generic "consensus halt error" channel perhaps? I'm not sure how/where to best document this. Please also let me know if tests need creating. Seems like the create empty block tests sometimes hit failures, I'll investigate tmrw Also please feel free to take over this PR, just thought I"d make it to help us with performance improvements. Happy to get this into an experimental release to test on mainnets. --- #### PR checklist - [ ] Tests written/updated - [x] Changelog entry added in `.changelog` (we use [unclog](https://github.com/informalsystems/unclog) to manage our changelog) - [ ] Updated relevant documentation (`docs/` or `spec/`) and code comments - [x] Title follows the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) spec --------- Co-authored-by: Sergio Mena <sergio@informal.systems> (cherry picked from commit 1c277c0) # Conflicts: # state/execution.go

This reverts commit 0246f4d.

First step to fixing #2925 PR'ing this to see if we have any test failures. Note that this is safe in the happy path, as Reap and CheckTx both share this same lock. The functionality behavior is that: - Full nodes and non-proposers `timeout_prevote` beginning should not block on updating the mempool - Block proposers get _very slight_ increased concurrency before reaping their next block. (Should be significantly fixed in subsequent PR's in - Reap takes a lock on the mempool mutex, so there is no concurrency safety issues right now. - Mempool errors will not halt consensus, instead they just log an error and call mempool flush. I actually think this may be better behavior? If we want to preserve the old behavior, we can thread a generic "consensus halt error" channel perhaps? I'm not sure how/where to best document this. Please also let me know if tests need creating. Seems like the create empty block tests sometimes hit failures, I'll investigate tmrw Also please feel free to take over this PR, just thought I"d make it to help us with performance improvements. Happy to get this into an experimental release to test on mainnets. --- - [ ] Tests written/updated - [x] Changelog entry added in `.changelog` (we use [unclog](https://github.com/informalsystems/unclog) to manage our changelog) - [ ] Updated relevant documentation (`docs/` or `spec/`) and code comments - [x] Title follows the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) spec --------- Co-authored-by: Sergio Mena <sergio@informal.systems>

…3362) First step to fixing #2925 PR'ing this to see if we have any test failures. Note that this is safe in the happy path, as Reap and CheckTx both share this same lock. The functionality behavior is that: - Full nodes and non-proposers `timeout_prevote` beginning should not block on updating the mempool - Block proposers get _very slight_ increased concurrency before reaping their next block. (Should be significantly fixed in subsequent PR's in #2925) - Reap takes a lock on the mempool mutex, so there is no concurrency safety issues right now. - Mempool errors will not halt consensus, instead they just log an error and call mempool flush. I actually think this may be better behavior? If we want to preserve the old behavior, we can thread a generic "consensus halt error" channel perhaps? I'm not sure how/where to best document this. Please also let me know if tests need creating. Seems like the create empty block tests sometimes hit failures, I'll investigate tmrw Also please feel free to take over this PR, just thought I"d make it to help us with performance improvements. Happy to get this into an experimental release to test on mainnets. --- #### PR checklist - [ ] Tests written/updated - [x] Changelog entry added in `.changelog` (we use [unclog](https://github.com/informalsystems/unclog) to manage our changelog) - [ ] Updated relevant documentation (`docs/` or `spec/`) and code comments - [x] Title follows the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) spec <hr>This is an automatic backport of pull request #3008 done by [Mergify](https://mergify.com). --------- Co-authored-by: Dev Ojha <ValarDragon@users.noreply.github.com> Co-authored-by: Sergio Mena <sergio@informal.systems>

First step to fixing cometbft#2925 PR'ing this to see if we have any test failures. Note that this is safe in the happy path, as Reap and CheckTx both share this same lock. The functionality behavior is that: - Full nodes and non-proposers `timeout_prevote` beginning should not block on updating the mempool - Block proposers get _very slight_ increased concurrency before reaping their next block. (Should be significantly fixed in subsequent PR's in - Reap takes a lock on the mempool mutex, so there is no concurrency safety issues right now. - Mempool errors will not halt consensus, instead they just log an error and call mempool flush. I actually think this may be better behavior? If we want to preserve the old behavior, we can thread a generic "consensus halt error" channel perhaps? I'm not sure how/where to best document this. Please also let me know if tests need creating. Seems like the create empty block tests sometimes hit failures, I'll investigate tmrw Also please feel free to take over this PR, just thought I"d make it to help us with performance improvements. Happy to get this into an experimental release to test on mainnets. --- - [ ] Tests written/updated - [x] Changelog entry added in `.changelog` (we use [unclog](https://github.com/informalsystems/unclog) to manage our changelog) - [ ] Updated relevant documentation (`docs/` or `spec/`) and code comments - [x] Title follows the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) spec --------- Co-authored-by: Sergio Mena <sergio@informal.systems>

First step to fixing cometbft#2925 PR'ing this to see if we have any test failures. Note that this is safe in the happy path, as Reap and CheckTx both share this same lock. The functionality behavior is that: - Full nodes and non-proposers `timeout_prevote` beginning should not block on updating the mempool - Block proposers get _very slight_ increased concurrency before reaping their next block. (Should be significantly fixed in subsequent PR's in - Reap takes a lock on the mempool mutex, so there is no concurrency safety issues right now. - Mempool errors will not halt consensus, instead they just log an error and call mempool flush. I actually think this may be better behavior? If we want to preserve the old behavior, we can thread a generic "consensus halt error" channel perhaps? I'm not sure how/where to best document this. Please also let me know if tests need creating. Seems like the create empty block tests sometimes hit failures, I'll investigate tmrw Also please feel free to take over this PR, just thought I"d make it to help us with performance improvements. Happy to get this into an experimental release to test on mainnets. --- - [ ] Tests written/updated - [x] Changelog entry added in `.changelog` (we use [unclog](https://github.com/informalsystems/unclog) to manage our changelog) - [ ] Updated relevant documentation (`docs/` or `spec/`) and code comments - [x] Title follows the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) spec --------- Co-authored-by: Dev Ojha <ValarDragon@users.noreply.github.com> Co-authored-by: Sergio Mena <sergio@informal.systems>

…3008) (cometbft#3362) First step to fixing cometbft#2925 PR'ing this to see if we have any test failures. Note that this is safe in the happy path, as Reap and CheckTx both share this same lock. The functionality behavior is that: - Full nodes and non-proposers `timeout_prevote` beginning should not block on updating the mempool - Block proposers get _very slight_ increased concurrency before reaping their next block. (Should be significantly fixed in subsequent PR's in - Reap takes a lock on the mempool mutex, so there is no concurrency safety issues right now. - Mempool errors will not halt consensus, instead they just log an error and call mempool flush. I actually think this may be better behavior? If we want to preserve the old behavior, we can thread a generic "consensus halt error" channel perhaps? I'm not sure how/where to best document this. Please also let me know if tests need creating. Seems like the create empty block tests sometimes hit failures, I'll investigate tmrw Also please feel free to take over this PR, just thought I"d make it to help us with performance improvements. Ha 103B5 ppy to get this into an experimental release to test on mainnets. --- - [ ] Tests written/updated - [x] Changelog entry added in `.changelog` (we use [unclog](https://github.com/informalsystems/unclog) to manage our changelog) - [ ] Updated relevant documentation (`docs/` or `spec/`) and code comments - [x] Title follows the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) spec <hr>This is an automatic backport of pull request cometbft#3008 done by [Mergify](https://mergify.com). --------- Co-authored-by: Dev Ojha <ValarDragon@users.noreply.github.com> Co-authored-by: Sergio Mena <sergio@informal.systems>

…3008) (cometbft#3362) First step to fixing cometbft#2925 PR'ing this to see if we have any test failures. Note that this is safe in the happy path, as Reap and CheckTx both share this same lock. The functionality behavior is that: - Full nodes and non-proposers `timeout_prevote` beginning should not block on updating the mempool - Block proposers get _very slight_ increased concurrency before reaping their next block. (Should be significantly fixed in subsequent PR's in - Reap takes a lock on the mempool mutex, so there is no concurrency safety issues right now. - Mempool errors will not halt consensus, instead they just log an error and call mempool flush. I actually think this may be better behavior? If we want to preserve the old behavior, we can thread a generic "consensus halt error" channel perhaps? I'm not sure how/where to best document this. Please also let me know if tests need creating. Seems like the create empty block tests sometimes hit failures, I'll investigate tmrw Also please feel free to take over this PR, just thought I"d make it to help us with performance improvements. Happy to get this into an experimental release to test on mainnets. --- - [ ] Tests written/updated - [x] Changelog entry added in `.changelog` (we use [unclog](https://github.com/informalsystems/unclog) to manage our changelog) - [ ] Updated relevant documentation (`docs/` or `spec/`) and code comments - [x] Title follows the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) spec <hr>This is an automatic backport of pull request cometbft#3008 done by [Mergify](https://mergify.com). --------- Co-authored-by: Dev Ojha <ValarDragon@users.noreply.github.com> Co-authored-by: Sergio Mena <sergio@informal.systems>

perf: Make mempool update async from block.Commit (backport cometbft#3008)

Make mempool update async from block.Commit

4e5e762

ValarDragon requested review from a team as code owners May 6, 2024 00:34

ValarDragon marked this pull request as draft May 6, 2024 00:37

melekes requested a review from hvanz May 6, 2024 07:08

Accidental double update

5af9100

ValarDragon marked this pull request as ready for review May 6, 2024 07:56

Add changelog

aaa676b

melekes reviewed May 6, 2024

View reviewed changes

melekes added the backport-to-v1.x Tell Mergify to backport the PR to v1.x label May 7, 2024

melekes approved these changes May 7, 2024

View reviewed changes

cason previously requested changes May 10, 2024

View reviewed changes

cason mentioned this pull request May 10, 2024

Mempool Rechecking all txs blocks consensus #2925

Open

Apply @cason's fixes

fbbf911

hvanz approved these changes May 16, 2024

View reviewed changes

state/execution.go Outdated Show resolved Hide resolved

state/execution.go Show resolved Hide resolved

ValarDragon mentioned this pull request May 17, 2024

Timeout ticker has incorrect behavior when two timeouts placed in quick succession #3091

Closed

Apply @hvans comments!

909f71e

ValarDragon requested a review from a team as a code owner May 17, 2024 12:58

sergio-mena reviewed May 22, 2024

View reviewed changes

.changelog/unreleased/features/3008-mempool-async-update.md Outdated Show resolved Hide resolved

sergio-mena reviewed May 22, 2024

View reviewed changes

Update .changelog/unreleased/features/3008-mempool-async-update.md

f191e39

Co-authored-by: Sergio Mena <sergio@informal.systems>

sergio-mena reviewed May 22, 2024

View reviewed changes

state/execution.go Outdated Show resolved Hide resolved

sergio-mena added this pull request to the merge queue May 22, 2024

Merged via the queue into cometbft:main with commit 1c277c0 May 22, 2024
36 checks passed

mmsqe mentioned this pull request May 23, 2024

feat: add api to allow get unconfirmed_tx by hash #3109

Merged

4 tasks

albertchon added a commit to InjectiveLabs/cometbft that referenced this pull request May 30, 2024

perf: Make mempool update async from block.Commit cometbft#3008

a95b70e

From cometbft#3008

beer-1 mentioned this pull request Jun 17, 2024

fix: use cms with version at simulation & checkTx cosmos/cosmos-sdk#20686

Closed

12 tasks

hvanz mentioned this pull request Jun 26, 2024

perf(mempool): disable rechecking when node is catching up #3343

Closed

4 tasks

sergio-mena assigned melekes Jun 28, 2024

sergio-mena added mempool bug Something isn't working labels Jun 28, 2024

sergio-mena added the backport-to-v1.x Tell Mergify to backport the PR to v1.x label Jun 28, 2024

mergify bot mentioned this pull request Jun 28, 2024

perf: Make mempool update async from block.Commit (backport #3008) #3362

Merged

4 tasks

sergio-mena added a commit that referenced this pull request Jun 28, 2024

Revert "perf: Make mempool update async from block.Commit (#3008)"

ffd883e

This reverts commit 0246f4d.

yihuang mentioned this pull request Sep 13, 2024

Problem: cometbft optimization not backported crypto-org-chain/cronos#1577

Closed

13 tasks

yihuang mentioned this pull request Oct 23, 2024

perf: Make mempool update async from block.Commit (backport #3008) crypto-org-chain/cometbft#3

Merged

7 tasks

yihuang added a commit to crypto-org-chain/cometbft that referenced this pull request Oct 25, 2024

Merge pull request #3 from yihuang/backport-async-mempool-update

05dc302

perf: Make mempool update async from block.Commit (backport cometbft#3008)

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

perf: Make mempool update async from block.Commit #3008

perf: Make mempool update async from block.Commit #3008

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

perf: Make mempool update async from block.Commit #3008

perf: Make mempool update async from block.Commit #3008

Uh oh!

Conversation

Uh oh!

PR checklist

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!