Skip to content

fix: rebroadcast txs recovered from reorg cache#3900

Open
iho wants to merge 1 commit into
mimblewimble:stagingfrom
iho:fix/reorg-cache-rebroadcast
Open

fix: rebroadcast txs recovered from reorg cache#3900
iho wants to merge 1 commit into
mimblewimble:stagingfrom
iho:fix/reorg-cache-rebroadcast

Conversation

@iho

@iho iho commented Jul 9, 2026

Copy link
Copy Markdown

Summary

On reorg, the reorg cache correctly re-adds previously seen txs to the local mempool, but it never rebroadcast them. Peers that did not keep those txs (or never saw them) would not learn about them until someone else re-announced.

As noted on #3489 by @antiochp: every tx successfully re-accepted from the reorg cache should also be treated as new and rebroadcast.

Closes #3489

Changes

  • reconcile_reorg_cache: call adapter.tx_accepted after a successful add_to_txpool
  • Skip rebroadcast when re-add fails (already in pool / invalid on new tip)
  • Integration test with a recording pool adapter

Retention period remains configurable via reorg_cache_period (default 30 minutes). This PR focuses on the missing rebroadcast path rather than changing the default window.

Test plan

  • cargo test -p grin_pool --test reorg_cache_rebroadcast

After a reorg we re-applied cached transactions to the local mempool but
never announced them to peers, so recovered txs could remain private to
the node. Call tx_accepted for each successfully re-accepted entry so
the network learns about them again.

Closes mimblewimble#3489

/// Re-apply cached transactions to the mempool after a reorg.
///
/// Txs that are successfully re-accepted are also rebroadcast via the pool

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The later discussion in #3489 explicitly questions unconditional rebroadcasting and suggests opt-in/default-off. This PR also leaves the issue’s retention-period request unchanged. Could we settle that policy here and use Refs #3489 rather than closing it unless both parts are handled?

// Only rebroadcast txs that were actually re-accepted (already-present
// or invalid-on-new-tip txs are skipped without network spam).
if self.add_to_txpool(&entry, header).is_ok() {
self.adapter.tx_accepted(&entry);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tx_accepted() is fine for a single tx, but here it runs in a loop under the pool write lock. Each peer queue has at most 100 free slots and silently drops overflow while reporting success, so a reorg recovering more than SEND_CHANNEL_CAP txs can lose later announcements. Could we schedule these through a paced bulk-relay path outside the pool lock?

assert_eq!(pool.reorg_cache.read().len(), 2);

// Simulate reorg: empty the pool while leaving reorg_cache intact.
pool.txpool.entries.clear();

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The recording adapter only counts callbacks. Could we add a real fork/reorg test for the production trigger, plus a bounded-queue adapter using SEND_CHANNEL_CAP to cover overflow? Otherwise the test misses the actual delivery failure mode.

@@ -0,0 +1,97 @@
// Copyright 2021 The Grin Developers

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

2026?

Comment thread pool/tests/common.rs
}
}

pub fn init_transaction_pool_with_adapter<B, P>(

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this duplicates the full PoolConfig literal from init_transaction_pool for one caller. Could the existing helper delegate here, or both use a shared test config, so they cannot drift?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants