Skip to content

graphql(ws): Lagged errors are swallowed, so slow subscribers silently miss events #489

Description

@euxaristia

Summary

Both /graphql/ws subscription streams route broadcast errors to None in their filter_map arms (crates/gitlawb-node/src/graphql/subscription.rs:31-46, :57-69). For a BroadcastStream, Err is RecvError::Lagged(n) once the 256-cap broadcast buffer (main.rs:288-289) overruns a slow consumer, and senders use let _ = tx.send(...), so lagging subscribers simply stop receiving some events with no error frame and no resync signal.

Impact

A slow subscriber (or one lagged by a burst of pushes to hot repos, which any peer can generate on its own public repos through the announce gate) silently misses ref_updates and task_events while the stream looks healthy: replication and UI triggers built on the stream miss events. Integrity-of-delivery, not confidentiality; the write-side announce gate holds.

Remediation

  1. Surface Lagged as an error/resync frame (or close the stream) so consumers know events were dropped.

Proposed labels: kind:bug, crate:node, subsystem:api.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    crate:nodegitlawb-node — the serving node and REST APIkind:bugDefect fix — wrong or unsafe behaviorsev:mediumDegraded but workaround existssubsystem:apiNode REST API request/response surface

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions