add_by_txids not evicting replaced txs in submit_package

[Randy808]

This issue is to track the problem described by @PeteClubSeven here:

Hi guys, thanks for adding broadcast_package support. I tried implementing electrum support in bark, typically we use core RPC or the REST API in this version of electrs. Unfortunately it looks like you've broken RBF'ing a TRUC package. It worked for a long time via the REST API but I updated to master so I can enable electrum support but both protocols are broken. I had Claude investigate it and it thinks the issue started when #227 was merged. Here is the summary it wrote up for additional context:

Affected: new-index branch since 7fed8f41 ("feat(electrum): add blockchain.transaction.broadcast_package", merged 2026-07-02 via #227). Reproduced at HEAD 4b348320. Both interfaces are affected — REST POST /txs/package and electrum blockchain.transaction.broadcast_package — since both go through Query::submit_package.

Symptom: the main thread panics and the daemon dies:

thread 'main' panicked at src/new_index/mempool.rs:519:17:
missing mempool edge for outpoint <O> (tx <C>)

Mechanism: Query::submit_package now calls Mempool::add_by_txids for the accepted txids immediately after bitcoind's submitpackage (src/new_index/query.rs, ~line 96–114). This bypasses the invariant the poll-based Mempool::update maintains — evicted txs are always removed before new ones are added, so two conflicting spenders of one outpoint never coexist in the view:

1. Tx A spending outpoint O is indexed via the normal poll.
2. A package containing tx C that RBF-replaces A (also spends O) is submitted; bitcoind evicts A, accepts C.
3. add_by_txids inserts C while A is still indexed → edges[O] is overwritten with C's entry.
4. Next poll evicts A → remove(A) deletes edges[O] (actually C's entry).
5. When C is later confirmed or evicted, remove(C) finds no edge for O → the assert! at mempool.rs:519 panics.

Repro: deterministic within seconds on regtest: index a spend of some outpoint, then submit a package containing a replacement of that spend between two mempool polls, then let both removals happen (mine a block). We hit it from wallet integration tests doing anchor/CPFP package broadcasts after an RBF bump.

Suggested direction: before add_by_txids, evict from the local view any indexed tx (plus descendants) that conflicts with an incoming package tx's prevouts — mirroring what the poll's remove-before-add ordering guarantees. For reference, mempool/electrs is unaffected because its submit_package proxies to bitcoind without touching the local view.

[PeteClubSeven]

Do you want me to test the new branch? We have a pretty comprehensive test suite so I'm more than happy to if it helps fix master!

[EddieHouston]

PR #234 is the correct and sufficient fix for the panic.

The root cause is commit 477c1a3, which changed mempool edge removal from ownership-aware cleanup to unconditional removal with a strict assertion. During RBF, removing the old transaction could therefore delete the replacement transaction’s edge; when the replacement was later removed, electrs panicked because that edge was missing.

PR #227 did not create this bug. Immediate insertion outside the polling loop already existed for broadcast_raw() since 2019. PR #227 extended the same behavior to package broadcasts, making the bug easier to reproduce with TRUC/RBF workflows.

PR #234 restores the correct ownership rule: only remove an edge when it belongs to the transaction being evicted. It fixes both ordinary and package RBF paths while retaining efficient cleanup.

A brief window can still exist where electrs locally contains both the replaced transaction and its replacement until the next mempool poll. That may temporarily affect histories or unconfirmed views, but it no longer corrupts edge bookkeeping or causes a crash.

Recommendation:

• Merge PR fix(mempool): tolerate missing/foreign edges on eviction #234 as the complete panic fix.
• Do not revert or modify PR feat(electrum): add blockchain.transaction.broadcast_package #227 for this crash.
• This add_by_txids not evicting replaced txs in submit_package #236 could be kept as an optional follow-up consistency improvement covering both broadcast_raw and submit_package.
• Keep fix(mempool): tolerate missing/foreign edges on eviction #234’s ownership check even if proactive conflict eviction is added later.

[EddieHouston]

Summary:

When broadcast_raw() or submit_package() succeeds, electrs immediately adds the accepted transaction(s) to its local mempool. If an accepted transaction replaces an already-indexed transaction, both temporarily coexist locally until the next polling update.

PR #234 makes this state safe by preserving edge ownership, but during the window electrs may expose stale or inconsistent unconfirmed histories, balances, transaction status, and descendants.

Suggested fix:

• Apply the solution at the shared Mempool::add_by_txid(s) layer, covering both ordinary broadcasts and package broadcasts.

• Before inserting accepted transactions, identify locally indexed transactions spending the same prevouts.

• Remove those conflicting transactions and all locally indexed descendants.

• Remove conflicts before adding the accepted transaction/package, matching Mempool::update() ordering.

• Handle an entire accepted package as one reconciliation operation so parent/child relationships remain consistent.

• Retain PR fix(mempool): tolerate missing/foreign edges on eviction #234’s ownership-checked edge removal as defense-in-depth.

• Add regression tests for both:

  • single-transaction RBF through broadcast_raw;
  • package/TRUC RBF through submit_package.

• Verify immediately after the broadcast—without waiting for a poll—that the old transaction and descendants have disappeared and the replacement’s histories, edges, and status are correct.