Skip to content

Fail fast when peer has no ring location #2069

@sanity

Description

@sanity

Nacho noted in PR #2064 that we should not route operations before a peer has finished joining the network, and more generally that we keep conflating network subscriptions with local client subscriptions.

Current behavior:

  • PUT/SUBSCRIBE/etc. traffic still flows during the short window where connection_manager.own_location() returns PeerKeyLocation { location: None }, so the router fallback exists to avoid dropping those entries.
  • Local client subscriptions share the same routing path as network seeding, leading to repeated complications in update delivery.

Follow-up plan:

  1. Decide the correct behavior when the local node lacks a ring location (likely fail fast with a clear “peer not joined” error).
  2. If we fail fast, propagate that error from PUT/SUBSCRIBE/GET/etc. and teach callers/tests (including client subscription handling) to retry after join completes.
  3. Revisit the architecture that conflates network subscriptions and local client subscriptions—consider a separate flow (e.g., internal notifications) so network routing isn’t used for purely local listeners.
  4. Once the above is in place, remove the router fallback (peer_distance_or_default) so routing only considers peers with valid locations.

Context:

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-networkingArea: Networking, ring protocol, peer discoveryE-mediumExperience needed to fix/implement: Medium / intermediateP-criticalCritical priorityS-needs-designStatus: Needs architectural design or RFCT-bugType: Something is broken

    Type

    No type

    Projects

    Status

    Triage

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions