Skip to content

discovery: define gossip syncer lifecycle after terminal handler errors #11015

Description

@ziggie1984

The gossip syncer's state-machine goroutine exits when a terminal state-handler
error occurs, but the syncer can remain in its previous state, such as
waitingQueryRangeReply, with no live handler. Its state is retained until the
peer disconnects.

This behavior predates #10992, but that PR highlighted it by adding new
channel-range validation errors and cleanup.

We should define an explicit lifecycle outcome for these failures:

  • retire or cancel the syncer;
  • transition it to a recoverable or failed state; or
  • disconnect the offending peer.

The solution should distinguish peer protocol violations from local/internal
errors, avoid retry loops against malicious peers, prevent stale queued replies
from being reused, notify the sync manager, and provide peer-attributable
logging or metrics.

Tests should cover terminal errors through ProcessQueryMsg and assert that the
reported state matches whether a handler is still active.

Context:

The separate issue in #10992 where exhausting maxReplies can process an
incomplete response as complete should be fixed in that PR rather than deferred
here.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions