fix(network): avoid disconnecting peers that return empty find responses at the chain tip by jvff · Pull Request #10732 · ZcashFoundation/zebra

jvff · 2026-06-17T21:13:08Z

Motivation

At the shared chain tip, FindBlocks/FindHeaders correctly return empty responses — there
are no new blocks to report. The stall tracker was treating these as misbehaviour,
disconnecting peers that were behaving correctly. This was introduced as a side effect of
the fix for GHSA-h9hm-m2xj-4rq9, which must remain active during catch-up.

Solution

Gate stall tracking on chain-tip state in PeerSet::route_p2c. When the node is at or
near the network tip, track_stalls is set to false and no stall event is emitted —
the peer's counter is neither incremented nor cleared. During catch-up the node is
meaningfully behind, so stall detection fires exactly as before.

Changes:

zebra-chain: add AT_OR_NEAR_TIP_THRESHOLD constant and is_at_or_near_network_tip
provided method to the ChainTip trait.
zebra-network: add chain_tip() getter to MinimumPeerVersion, replacing the
removed chain_tip_height() method; gate track_stalls on is_syncing in
route_p2c.

Tests

Four unit tests were added:

find_blocks_stall_not_tracked_when_at_tip: Verifies that a peer sending empty FindBlocks responses is not disconnected when the node is at the chain tip, confirming the stall tracker is suppressed by the fix.
find_blocks_stall_tracked_when_syncing: Verifies that a peer sending only empty FindBlocks responses is still disconnected after exceeding the stall threshold during initial sync, confirming the security property from GHSA-h9hm-m2xj-4rq9 is preserved.
find_blocks_stall_tracked_when_tip_unknown: Verifies that stall tracking remains active when the chain tip is unknown (empty state), so the node is protected even before it has synced its first block.
find_blocks_stall_count_preserved_across_tip_transition: Verifies that stall counts accumulated during sync are not reset when the node transitions to at-tip and back, so a peer cannot avoid detection by sending one useful response when the node nears the tip.

A regression test was added that spawns a regtest network with only two nodes. One mines 100 blocks, then the other syncs. When the tip is reached, the test ensures that the nodes are still connected.

Specifications & References

Issue: Stall tracker false-positive: an internal Zebra (or zcashd) relaying through a single upstream Zebra disconnects it and self-isolates #10715
Security advisory preserved: GHSA-h9hm-m2xj-4rq9 (CVE-2026-44499)

Follow-up Work

We might want a

AI Disclosure

No AI tools were used in this PR
AI tools were used: Claude Sonnet for discussing the solution and coding it

PR Checklist

The PR title follows conventional commits format: type(scope): description
The PR follows the contribution guidelines.
This change was discussed in an issue or with the team beforehand.
The solution is tested.
The documentation and changelogs are up to date.

Copilot

Pull request overview

This PR adjusts Zebra’s peer stall-tracking so that peers are no longer disconnected for empty FindBlocks/FindHeaders responses when Zebra is already at (or near) the network chain tip, while preserving the existing stall-disconnect behavior during catch-up syncing.

Changes:

zebra-chain: adds an “at/near tip” threshold constant and a provided ChainTip::is_at_or_near_network_tip() helper.
zebra-network: exposes MinimumPeerVersion::chain_tip() and uses it to gate stall tracking in PeerSet::route_p2c; updates handshake start_height derivation accordingly.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
zebra-network/src/peer/minimum_peer_version.rs	Replaces `chain_tip_height()` with `chain_tip()` accessor for callers needing richer tip context.
zebra-network/src/peer/handshake.rs	Computes `start_height` from `chain_tip().best_tip_height()` (defaulting to height 0).
zebra-network/src/peer_set/set.rs	Disables find-response stall event emission when at/near tip; keeps it enabled while syncing.
zebra-chain/src/chain_tip.rs	Introduces `AT_OR_NEAR_TIP_THRESHOLD` and `is_at_or_near_network_tip()` to centralize the tip proximity decision.

…king on chain-tip state Carry of ZcashFoundation/zebra#10732 (open, closes their #10715) to fix the stall-tracker false-positive that disconnects a single-upstream internal node at the tip (Luxor). Drop on the next subtree pull after #10732 merges upstream. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

In some places the `MinimumPeerVersion` becomes the way to access the `ChainTip`, so we should make that explicit instead of adding unrelated methods to `MinimumPeerVersion`.

Refactor to keep `MinimumPeerVersion` more focused.

A helper method to check if the node can be considered to be synced.

Copilot

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated 1 comment.

Empty find block or find headers responses are expected once nodes are synced.

Ensure that the stall tracker only disconnects peers while the node is syncing.

Empty find blocks or find headers responses can slow down synchronization, so the peers should be penalized with a disconnection.

Ensure that the initial behavior is to disconnect from peers that return empty find blocks or headers responses.

Ensure that if the node falls behind, it will still track stalls from peers.

Simulate the scenario described in the issue, where an internal Zebra node disconnects from its upstream (and sole peer) because it has finished syncing.

List the fix to not disconnect from peers missing blocks when synced.

Copilot

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated 1 comment.

+/// The maximum estimated distance to the network chain tip that is considered "at or near tip".
+///
+/// Allows for normal block-time variance and propagation delay.
+/// Most chain forks are 1–7 blocks long; 1 is used in sync progress tracking.
+pub const AT_OR_NEAR_TIP_THRESHOLD: block::HeightDiff = 2;


arya2

Looks great! Thank you.

arya2 · 2026-06-26T00:17:10Z

+    fn is_at_or_near_network_tip(&self, network: &Network) -> bool {
+        match self.estimate_distance_to_network_chain_tip(network) {
+            None => false,
+            Some((distance, _height)) => distance <= AT_OR_NEAR_TIP_THRESHOLD,


Perhaps we could use a value that would work for the getblocktemplate RPC too and use a single constant for both, MAX_ESTIMATED_DISTANCE_TO_NETWORK_CHAIN_TIP is currently 100, I think that's more reasonable.

Should I reuse MAX_ESTIMATED_DISTANCE_TO_NETWORK_CHAIN_TIP or should just I just set the AT_OR_NEAR_TIP_THRESHOLD to have the same value?

arya2 · 2026-06-26T00:28:43Z

Do we want to update FIND_RESPONSE_STALL_THRESHOLD to be higher in this PR?

I don't think we need to change it 🤔

arya2 · 2026-06-26T00:42:37Z

We could also add a config flag for disabling the stall tracker altogether (we'll get rid of it anyway if we replace our checkpoints with the hashes of chunks of all of the checkpointed block hashes, done in the experimental sync PR).

jvff · 2026-06-26T21:38:32Z

We could also add a config flag for disabling the stall tracker altogether (we'll get rid of it anyway if we replace our checkpoints with the hashes of chunks of all of the checkpointed block hashes, done in the experimental sync PR).

Sure, I opened an issue for that (#10842). We can prioritize it if needed or close it if we end up not needing it anymore.

jvff temporarily deployed to dev June 17, 2026 21:13 — with GitHub Actions Inactive

jvff temporarily deployed to dev June 17, 2026 21:15 — with GitHub Actions Inactive

gustavovalverde requested a review from Copilot June 18, 2026 00:49

Copilot started reviewing on behalf of gustavovalverde June 18, 2026 00:49 View session

Copilot AI reviewed Jun 18, 2026

View reviewed changes

Comment thread zebra-chain/src/chain_tip.rs

Comment thread zebra-network/src/peer_set/set.rs Outdated

jvff temporarily deployed to dev June 18, 2026 20:18 — with GitHub Actions Inactive

jvff temporarily deployed to dev June 18, 2026 20:19 — with GitHub Actions Inactive

jvff temporarily deployed to dev June 18, 2026 20:22 — with GitHub Actions Inactive

jvff force-pushed the jvff/ignore-stall-events-if-synced branch from ad77fdf to 33914be Compare June 19, 2026 19:14

jvff temporarily deployed to dev June 19, 2026 19:14 — with GitHub Actions Inactive

jvff temporarily deployed to dev June 19, 2026 19:16 — with GitHub Actions Inactive

jvff self-assigned this Jun 19, 2026

jvff added C-enhancement Category: This is an improvement A-network Area: Network protocol updates or fixes labels Jun 19, 2026

jvff force-pushed the jvff/ignore-stall-events-if-synced branch from 33914be to 779e11f Compare June 19, 2026 19:41

jvff temporarily deployed to dev June 19, 2026 19:41 — with GitHub Actions Inactive

jvff temporarily deployed to dev June 19, 2026 19:43 — with GitHub Actions Inactive

jvff marked this pull request as ready for review June 22, 2026 14:13

jvff requested a review from arya2 June 25, 2026 20:18

jvff added 3 commits June 25, 2026 21:15

Add chain_tip getter to MinimumPeerVersion

b304522

In some places the `MinimumPeerVersion` becomes the way to access the `ChainTip`, so we should make that explicit instead of adding unrelated methods to `MinimumPeerVersion`.

Remove MinimumPeerVersion::chain_tip_height

8eae5ac

Refactor to keep `MinimumPeerVersion` more focused.

Add ChainTip::is_at_or_near_network_tip

cad02cc

A helper method to check if the node can be considered to be synced.

Copilot AI review requested due to automatic review settings June 25, 2026 21:16

jvff force-pushed the jvff/ignore-stall-events-if-synced branch from 779e11f to e48127e Compare June 25, 2026 21:16

Copilot started reviewing on behalf of jvff June 25, 2026 21:16 View session

Copilot AI reviewed Jun 25, 2026

View reviewed changes

Comment thread zebra-network/src/peer_set/set.rs Outdated

jvff force-pushed the jvff/ignore-stall-events-if-synced branch from e48127e to 649ff3f Compare June 25, 2026 21:35

jvff added 7 commits June 25, 2026 21:39

Only count stalls while syncing

a82f320

Empty find block or find headers responses are expected once nodes are synced.

Test if stalls aren't tracked when close to tip

5fc01a7

Ensure that the stall tracker only disconnects peers while the node is syncing.

Test disconnection after empty find responses

6994431

Empty find blocks or find headers responses can slow down synchronization, so the peers should be penalized with a disconnection.

Also test if the chain tip state is empty

42135ed

Ensure that the initial behavior is to disconnect from peers that return empty find blocks or headers responses.

Test stall counts are preserved after sync

3ac299f

Ensure that if the node falls behind, it will still track stalls from peers.

Add a regression test for the disconnection issue

399da13

Simulate the scenario described in the issue, where an internal Zebra node disconnects from its upstream (and sole peer) because it has finished syncing.

Update changelog

f18537a

List the fix to not disconnect from peers missing blocks when synced.

Copilot AI review requested due to automatic review settings June 25, 2026 21:39

jvff force-pushed the jvff/ignore-stall-events-if-synced branch from 649ff3f to f18537a Compare June 25, 2026 21:39

Copilot started reviewing on behalf of jvff June 25, 2026 21:40 View session

Copilot AI reviewed Jun 25, 2026

View reviewed changes

arya2 approved these changes Jun 26, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix(network): avoid disconnecting peers that return empty find responses at the chain tip#10732

fix(network): avoid disconnecting peers that return empty find responses at the chain tip#10732
jvff wants to merge 10 commits into
mainfrom
jvff/ignore-stall-events-if-synced

jvff commented Jun 17, 2026 •

edited

Loading

Uh oh!

Copilot AI left a comment

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Uh oh!

Uh oh!

Copilot AI left a comment

Uh oh!

arya2 left a comment

Uh oh!

arya2 Jun 26, 2026

Uh oh!

jvff Jun 26, 2026

Uh oh!

arya2 Jun 26, 2026

Uh oh!

jvff Jun 26, 2026

Uh oh!

arya2 commented Jun 26, 2026

Uh oh!

jvff commented Jun 26, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

jvff commented Jun 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Motivation

Solution

Tests

Specifications & References

Follow-up Work

AI Disclosure

PR Checklist

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

arya2 left a comment

Choose a reason for hiding this comment

Uh oh!

arya2 Jun 26, 2026

Choose a reason for hiding this comment

Uh oh!

jvff Jun 26, 2026

Choose a reason for hiding this comment

Uh oh!

arya2 Jun 26, 2026

Choose a reason for hiding this comment

Uh oh!

jvff Jun 26, 2026

Choose a reason for hiding this comment

Uh oh!

arya2 commented Jun 26, 2026

Uh oh!

jvff commented Jun 26, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

jvff commented Jun 17, 2026 •

edited

Loading