Repository navigation
ibd: reuse the confirmed getheaders tail until the tip changes - #1056
Conversation
Catch-up getheaders still builds the work-path prefix from the in-memory walk on every ask. The confirmed-chain tail is remembered on the IBD work state, keyed by published tip height and hash, and reused until that pair changes. Tip-follow locators are unchanged.
Clippy rejects the nested height, hash, and hash-list tuple on the IBD work state. The cache is a small struct with those three fields.
![rearden-grok[bot]](https://avatars.githubusercontent.com/u/730881?s=60&v=4){kind=small}
There was a problem hiding this comment.
Summary
The change caches the confirmed-chain getheaders tail on IbdWorkState, keyed by Query::published_tip() height and hash, and still builds the work-path prefix on every ask through header_ask_locator → ibd_header_locator. That split is correct: a same-height reorg changes the published hash (disconnect lowers the tip, then the new block publishes a different hash), locator_hashes errors are not cached, and hub.tip_hash() is the in-memory published snapshot rather than a header_at_height walk, so it does not bump header_lookup_count. Production send_getheaders runs only on the header thread while it holds the state mutex, and tip-follow locators are untouched. No correctness bug turned up; the residual gaps are a change-narrating comment and a test that never holds height fixed while swapping the tip hash.
Issue counts by severity
- bugs: 0
- suggestions: 2
- nits: 0
The doc named the old per-ask store read. Say when the tail is rebuilt.
Invalidate the tip and confirm a different block at that height. The next due ask rebuilds the confirmed tail and drops the replaced hash. The walk prefix can still name the hash it learned at origin.
The separate test opened another hub and mined thirty blocks. Those asks now run on the seeded header-walk hub after a two-block chain.
Folding the tail checks into the seeded walk put that test over the cognitive-complexity limit. The same hub still runs them, from helpers.
1 participant
Summary
Catch-up
getheadersstill builds the work-path prefix from the in-memory header walk on every ask. The confirmed-chain tail thatquery.locator_hashesused to rebuild on each send is remembered on IBD work state until the published tip height and hash both change. A second ask at the same tip does not walk the header store. Tip-follow locators are unchanged.Test plan
cargo test -p rbitcoin-net --lib second_getheaders_reuses_confirmed_locator_tail(same tip reuses the tail; a new tip hash rebuilds it; the locator still starts at the stored path tip)rbitcoin-netfilters for header period, unsolicited lookahead, stored-queue refill, stray batches, stall disconnect, redial budget, below-floor intake, and rate-limit disconnect