Skip to content

bridge: subscribe does not replay cached diagnostics — late subscribers miss initial diagnostics push #131

@bug-ops

Description

@bug-ops

Description

When a client subscribes to an lsp-diagnostics:// URI after the LSP server has already published its first publishDiagnostics notification for that file, the subscriber will never see those diagnostics until the next LSP push. The subscription silently succeeds but delivers no data.

This is marked TODO(critic-S3) in crates/mcpls-core/src/lib.rs at the point where notify_resource_updated is conditionally sent.

Reproduction Steps

  1. Start mcpls against a project.
  2. Open a file (triggering textDocument/didOpen).
  3. Wait for the initial publishDiagnostics push from the LSP server.
  4. Subscribe via resources/subscribe for the file's lsp-diagnostics:// URI.
  5. Observe: no notifications/resources/updated is sent for the already-cached diagnostics.
  6. The subscriber must wait for the next LSP-triggered publishDiagnostics push before receiving any data.

Expected Behavior

On subscribe, if cached diagnostics already exist for the requested URI, notify_resource_updated should be sent immediately (or the cached data should be replayed via read_resource).

Actual Behavior

No immediate notification is sent. The client is left waiting indefinitely if the LSP server does not re-push diagnostics.

Environment

  • Version: HEAD 0f40608
  • Features: all-features

Logs / Evidence

crates/mcpls-core/src/lib.rs — TODO comment:

// TODO(critic-S3): on subscribe, replay cached diagnostics once
// so clients that subscribe after the first PublishDiagnostics
// do not have to wait for the next LSP push.

Metadata

Metadata

Assignees

No one assigned

    Labels

    P3Low: cosmetic, edge case unlikely in practicebugSomething isn't workingmcpls-coremcpls-core crate changes

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions