You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(zebrad): keep active mempool through sync noise (#10929)
* fix(mempool): keep active mempool through sync noise
Keep an already-active mempool running when the legacy sync-status heuristic temporarily reports that Zebra is far from the tip.
The initial activation gate still waits for near-tip sync status, but once active, transient sync noise no longer drops mempool storage or cancels queued transaction verification. Chain tip resets reinitialize the active mempool directly so pending transactions can be requeued and reverified.
Also raise the close-to-tip threshold to accept recent sync batches averaging up to 100 blocks, matching the intended near-tip behavior covered by the updated tests.
(cherry picked from commit 78d1a5e)
* test(mempool): rename legacy sync wording
* docs(zebrad): clarify mempool activation state update
* fix(zebrad): revert global close-to-tip threshold; correct changelog
The mempool latch (keeping an already-active mempool alive through transient
far-from-tip sync status) is what closes the peer-toggle issue. The
MIN_DIST_FROM_TIP 20->101 raise additionally loosened every other consumer of
`is_close_to_tip()` — health readiness, sync gossip, block notify, and the
getblocktemplate mining RPC — which was unjustified, so revert it.
Also rewrite the CHANGELOG entry to describe only the latch (getblocktemplate is
not latched; it is still bounded by the network-tip-distance estimate), and drop
leftover "legacy" wording missed by the rename commit.
* refactor(zebrad): tidy mempool activation log and reset tip-action binding
Address review on #10929:
- Move the "activating mempool: Zebra is close to the tip" log out of
`enable_at_tip` into the initial-activation arm. The helper is also called from
the chain-tip reset path, where sync status may report far-from-tip, so the log
was misleading there (Copilot).
- Bind the `Reset` action via a pattern match instead of `matches!`, dropping the
`expect` and the `unwrap` in the reset branch (jvff).
* fix(zebrad): address mempool PR review comments
- Point the CHANGELOG entry at #10929 instead of the closed, unmerged #10926
(gustavovalverde).
- Evaluate `is_caught_up_to_start()` once per `poll_ready` and pass it into
`update_state()` instead of recomputing it there (also avoids a duplicate
debug-activation log) (gustavovalverde).
- Clarify the `fully_notified` assertion message: it is a placeholder that is
always None pending the regtest network-info TODO, not active-mempool-specific
(jvff).
---------
Co-authored-by: Dev Ojha <ValarDragon@users.noreply.github.com>
Co-authored-by: Dev Ojha <dojha@berkeley.edu>
0 commit comments