Skip to content

Trace WebSocket dispatch latency on request - #889

Merged
wieslawsoltes merged 1 commit into
mainfrom
diagnose/websocket-dispatch-latency-289
Sep 21, 2026
Merged

wieslawsoltes merged 1 commit into
mainfrom
diagnose/websocket-dispatch-latency-289

Conversation

@wieslawsoltes

Copy link
Copy Markdown
Collaborator

Problem

The unchanged Code OSS workspace now meets functional acceptance but narrowly misses the two-second first-paint gate. Native WebSocket queue ownership could not be measured without logging application payloads.

Change

Add opt-in WEBSCENE_WEBSOCKET_TRACE diagnostics at the transport boundary. Each dispatched event emits one JSON metadata record containing socket id, event type, byte count, enqueue/dispatch timestamps, queue delay, and remaining queue depth. Payload bytes, URLs, protocols, close reasons, and user data are never logged. The disabled path performs two timestamp captures at enqueue and one cached environment check at dispatch.

The exact Code OSS run used this trace to prove #888 dispatches the extension-host Ready frame in about 8 ms despite an 11.87 MB management-socket backlog, and to move #280 to same-socket binary processing.

Validation

  • Focused native WebSocket/FileReader suite passes.
  • Existing 100-cycle WebSocket latency and 20-cycle protocol gates pass.
  • Exact installed package retains the remote root/provider/five resolved/model/rendered children and 64 Explorer nodes.
  • Trace schema inspected across four sockets; no payload content is emitted.

Tracks #280 and #289.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant