Prevent window.postMessage traffic from starving due timers

[wieslawsoltes]

Parent scheduler issue: #287
Remote handshake attribution: #289
Workspace acceptance: #252
Runtime collision/dependency: draft PR #292

Problem

WebScene drains window.postMessage tasks after the Worker/ServiceWorker/MessagePort/WebSocket rotation but before any due timer. A message handler that refills its own window-message queue can therefore prevent a zero-delay timer from running indefinitely, even after the asynchronous-message fairness fix proven locally for #287.

This matches the unchanged Code OSS remote extension-host bootstrap. Its protocol writer requests a timer-coalesced 1,071,424-byte initialization send, while iframe/window messaging remains active. The timer request is retained immediately, but native WebSocket.send is not entered for several seconds.

Reduced evidence

On exact WebScene main 1bd8596e3dc07a3281204504acad379eb1f6bc78 plus local unpushed #287 candidate b75d37958ef7ce3f73a5b08de6b0516b0f8f57eb, the product-shaped 20-cycle oracle adds one self-refilling window.postMessage source alongside Worker, MessagePort, WebSocket, FileReader, and the 1,071,425-byte body:

• protocol flush maximum: 3229.87 ms
• p95: 96.456 ms
• window-message tasks before the delayed flush: 700,000
• Worker: 0; MessagePort: 1; WebSocket: 1; FileReader: 0
• window-message queue remains self-refilling rather than growing without bound

Without the window source, the same candidate reports maximum 0.204 ms and p95 0.157 ms. The packaged unchanged-Code trace independently measured protocol-send request → native WebSocket.send entry at 3698 ms, followed by a 0.783 ms send and 0.834 ms microtask. The close agreement identifies task arbitration rather than wire throughput.

Evidence: /private/tmp/webscene-289-b75d3795-window-message-oracle.log (SHA-256 d2f77ef271fe8863b36370e77feba57c730939bcf7844e8a6f955777fcc5416d) and /private/tmp/vscode-252-product-b75d3795.log (SHA-256 f58b40413fe5dd30567d0d6a3d207b668fd07bea96b594aae9c5568509a38252).

Scope

Make due timers fair with the window.postMessage task source while preserving FIFO ordering, origin/source/transfer semantics, bounded queue limits, and the four-source Worker/ServiceWorker/MessagePort/WebSocket rotation. Do not alter transferred MessagePort lifetime ownership or add Code OSS special cases.

Draft #292 touches the same runtime dispatcher. Its DOM-listener retirement work is semantically independent, but this implementation must wait for #292 to merge or split, then rebase without regressing #281's four-source rotation.

Acceptance

• A product-neutral native/browser fixture runs the actual 13-byte header + 1,071,425-byte body, timer-coalesced protocol write against continuously ready window/Worker/MessagePort/WebSocket/FileReader sources for 20 cold/warm cycles.
• Due timer latency is p95 ≤ 25 ms and max ≤ 100 ms; at most four window-message tasks run before a due timer.
• FIFO window.postMessage order, source, origin, transferred ports, microtask checkpoints, and existing queue byte/count caps remain correct.
• Cancellation/navigation/realm teardown drops stale queued messages and timers without callback, port, socket, or V8-handle retention.
• Existing Add service worker client messaging and navigation lifecycle #281 source rotation, Wake native runtime for queued WebSocket events #284 socket wake/fairness, Prevent WebSocket traffic from starving FileReader completion tasks #287 protocol timing, iframe/message-port, and adjacent idle-platform/ServiceWorker gates pass.
• Across 20 cycles, task/wakeup/scene counts, queue depth/age, V8 heap, and RSS remain bounded.
• Unchanged Code OSS reaches remote Initialized, exact provider root/five children/five Explorer rows, and first-child paint within Qualify remote workspace bootstrap, Explorer contents, and watcher refresh #252's 2-second bound.

[wieslawsoltes]

Local candidate b485f6aa (stacked on #287 candidate b75d3795, both unpushed) adds due-timer arbitration against the independently refilling window-message task source.

The exact reduced failure now passes twice:

• run 1: 20 cycles, protocol-flush p95 0.134 ms, max 0.268 ms, window tasks before flush max 2
• run 2: p95 0.184 ms, max 0.323 ms, window max 2, Worker max 1, MessagePort max 1, WebSocket max 0
• 1,071,425-byte body; Ready p95 4.112 ms; Initialized p95 12.293 ms; send-return p95 0.905 ms
• 342 timers, 648 microtask checkpoints, 47 signalled wakes, 2 scene builds
• V8 heap after low-memory collection: 657,260 bytes; process RSS max: 121,307,136 bytes

Chromium 151 control passes 45/45 with protocol-flush p95 0.100 ms, max 0.300 ms, and zero competing messages before the flush. Native adjacent gates pass: post-message style batching, Worker configuration ordering, idle V8 platform, ServiceWorker clients (100 cycles), and cooperative iframe hydration.

Evidence:

• /private/tmp/webscene-293-window-message-candidate.log, SHA-256 143320b7b0e4278cf6bc2c3e8cb83cd71bb11f1f0c83437532e869e4f4aaf7b0
• /private/tmp/webscene-293-window-message-candidate-repeat.log, SHA-256 bc0a04287d46429c2e7891faac557675cc00181ce7cb651ce5bd585fc223a3b9
• /private/tmp/webscene-293-chromium-control.log, SHA-256 70bba0c382ad165f41626b8365b9f3a39494b1a967fd9fc4786185a0c873d1e9
• /private/tmp/webscene-293-adjacent-gates.log, SHA-256 2f1887c661af2a69ea634c86ebe805ccf45d6cc6bd14365eb77d843544e48138

The candidate remains local. Draft #292 still collides with the dispatcher and must land or split before any push/PR. Unchanged Code OSS #252 remains the required product gate.

[wieslawsoltes]

Unchanged Code OSS product validation rejects b485f6aa as sufficient for #252, despite the reduced window-message oracle passing:

Phase	Timestamp / duration
Remote transport connected	1789662766314
Ready / first protocol message	1789662767887
Initialization data created	1789662768385 (497.258 ms)
Serialized	1789662768392 (7.464 ms, 1,070,402 bytes)
Protocol send requested	1789662768392
Native WebSocket.send entered	1789662771870 (+3478 ms)
Native send returned	0.815 ms
Send microtask	0.857 ms, bufferedAmount=0
Remote Initialized	1789662771989 (Ready→Initialized ~4102 ms)

The exact remote root, provider registration, five resolved/model children, and five Explorer rows remained correct, but the two-second contract failed. Therefore window.postMessage is a proven generic starvation source, yet it is not the sole owner of the packaged product delay. The candidate remains local/unpushed and this issue cannot claim the product acceptance checkbox.

App RSS was 732,288 KiB; observed process-tree RSS was 1,360,624 KiB. App, guardian, server, extension host, agent host, watcher, and Copilot descendants were terminated; port 56322 is free.

Evidence: /private/tmp/vscode-252-product-b485f6aa.log, SHA-256 cb9b7c5c843da4badc2b8c7e35c2850b41598c70b7510afce7c94bee5b5a2a26.

[wieslawsoltes]

The corrected packaged histogram makes #293 secondary to #297 for the current product gate. The decisive 50 ms timer was overdue 2459.903 ms: one fetch task consumed 2457.097 ms, while window-message work was only 0.107 ms. Within that fetch task, the built-in light_vs.json promise microtask checkpoint consumed 2424.455 ms.

#293's reduced generic defect and local fix remain valid, but it does not qualify unchanged #252 and must not be presented as the current product owner.

[wieslawsoltes]

The generic scheduler fix for this reduced starvation class has now landed through PR #347 at dbd7351a88415d369ea322c692153474fb7a933c.

The implementation alternates due timers with all observable ready task sources, including window-message traffic, and preserves run-to-completion plus the microtask checkpoint. Exact-base product-shaped validation measured the 1.07 MiB protocol flush at 0.157 ms p95 / 0.274 ms max, with no more than 2 competing tasks first and queue high-water 4. This issue remains open until unchanged packaged Code OSS #252 confirms the downstream product timing.