[niteshbalusu11]

Summary

reconsiderblock re-applied each restored invalidated path on its own. Each path had to outweigh the current tip by itself, and a path whose parent sat in a refused path hit branch parent not on chain, which was swallowed. Nothing then picked the best chain, and a reconsidered block that lost was forgotten as a candidate. Core clears the flags, re-adds the blocks to setBlockIndexCandidates, and runs ActivateBestChain.

 reconsider_block_inner (chain.rs)
   clear invalid marks on hash, ancestors, related paths
-  for path in paths: accept_branch_inner(path)      // each must win alone
-  if hash still off chain: accept_branch_inner(assemble(hash))
+  fork_tips += hash + each path's tip               // candidates again
+  try_apply_after_invalidate()                      // one most-work pick, as after invalidate

Evidence

Same RPC sequences on Core 31.1 and rbitcoin (regtest):

Sequence	Core 31.1	master	this branch
A: mine a1..a10; invalidateblock a10, invalidateblock a8; mine b8, b9; reconsiderblock a8	a10 (h=10)	b9 (h=9)	a10
B: mine a1..a5; invalidateblock a5; mine b5, b6; reconsiderblock a5; invalidateblock b5	a5 (h=5)	a4 (h=4)	a5

• New tests reconsider_activates_the_most_work_chain (A) and invalidate_falls_back_to_a_reconsidered_block (B).
  • Before: both fail on the final tip assertion.
  • After: pass. invalid_child_missing_parent_and_linked_reconsider still passes.
• fmt, clippy, ast-grep, cargo test --workspace, and ci-os-smoke.sh pass locally.

Merge Danger

Door: two-way

Blast Radius: chain selection

Only reconsiderblock changes, plus the later invalidateblock fallback. It now uses the same most-work pick invalidateblock already used, including its precious and first-seen tie-breaks. A losing branch stays a candidate in fork_tips and still needs strictly more work to connect. Peer-driven reorgs are unchanged.

🤖 Generated with Claude Code

[niteshbalusu11]

Closing in favor of #1080. Two small fixes each broke other cases, so I'd like your view on the design first.