fixes to mempool handling

[pompon0]

• made handlePeerUpdates in mempool reactor run even if Broadcast = false, so that CheckTx failures are accounted properly.
• make autobahn producer wait on a AtomicRecv instead of TxsAvailable channel so that block production is not blocked by execution.

[github-actions]

The latest Buf updates on your PR. Results from workflow Buf / buf (pull_request).

Build	Format	Lint	Breaking	Updated (UTC)
✅ passed	✅ passed	✅ passed	✅ passed	Apr 23, 2026, 8:49 AM

[codecov]

Codecov Report

❌ Patch coverage is 76.40449% with 42 lines in your changes missing coverage. Please review.
✅ Project coverage is 59.37%. Comparing base (63f25b1) to head (64c226c).
⚠️ Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
sei-tendermint/internal/mempool/tx.go	72.90%	41 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3281      +/-   ##
==========================================
+ Coverage   58.31%   59.37%   +1.06%     
==========================================
  Files        2085     2072      -13     
  Lines      209061   170097   -38964     
==========================================
- Hits       121913   100996   -20917     
+ Misses      78355    60333   -18022     
+ Partials     8793     8768      -25     

Flag	Coverage Δ
sei-chain-pr	74.62% <76.40%> (?)
sei-db	69.36% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
sei-tendermint/internal/autobahn/producer/state.go	79.16% <100.00%> (+0.29%)	⬆️
sei-tendermint/internal/mempool/mempool.go	72.82% <100.00%> (-0.11%)	⬇️
sei-tendermint/internal/mempool/reactor/reactor.go	79.62% <100.00%> (ø)
sei-tendermint/internal/mempool/tx.go	80.00% <72.90%> (-3.34%)	⬇️

... and 1795 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[wen-coding]

nit: do we need to add any counter at least? Just in case some validator goes Haywire and send us the same transaction tons of times and waste all bandwidth for nothing.

[pompon0]

There are more serious holes in the tendermint p2p protocol than that. I don't thing we should spend much time on fixing them. If you feel the need to add more metrics for better visibility feel free to do so.

[wen-coding]

So what happens if some spammer keeps sending us an invalid tx which will fail at app CheckTx? (let's say a bad signature.)

The tx will be added to the cache, fail CheckTx, and then removed from the cache here? Should we also add a separate counter for certain app-level failures which should not happen to prevent against spamming?

[pompon0]

I would really love to avoid dealing with this code and just jump to rewriting it for autobahn. Your concern is valid though, of course.