Remove fixed delay from remote filesystem provider responses

[wieslawsoltes]

Parent/product acceptance: #252
Release coordination: #227

Problem

An unchanged Code OSS vscode-remote workspace reaches the correct new-document root and registers the stock RemoteFileSystemProviderClient, but WebScene takes about eight seconds to complete the first direct IFileService.resolve for a five-entry local fixture. Chromium against the same Code OSS server/provider/root completes the resolve in 328 ms and paints the five Explorer rows in 715 ms.

This is below the picker/navigation/workspace-context layers already qualified by #247 and AppScene#124. It is a generic native WebScene request/response latency boundary in the remote filesystem path and blocks #252's provider/Explorer performance gate.

Retained evidence

Exact source inputs:

• VS Code OSS 645f29cc3176500b4b5762ba887cf2a7f0ffdf2c
• WebScene 28d1d649e927c665ff05844197af44f223edf952
• AppScene 1420e227e52579a097e7ae52a2cadb41cf073e4d
• Node 24.18.1
• fixture root /private/tmp/webscene-247-fixture/beta

Clean native trace after await fileService.activateProvider('vscode-remote'):

• selected URI equals the only IWorkspaceContextService root
• provider registered before resolve
• resolve: 8,139.3 ms
• first five Explorer rows: 12,324.0 ms from observer start
• resolved child set is exact: .hidden.txt, readme-link, README.md, subdir/, unicodé.txt
• rendered rows: 5; Explorer DOM nodes: 64

A separate overlapping run is retained as contaminated timing and excluded from the performance conclusion; it independently measured an almost identical 8,132.1 ms resolve.

Headless Chrome 153 against the same server build, stock provider, and exact root:

• resolve: 328.2 ms
• first five Explorer rows: 714.9 ms
• provider/root/resolved/model/rendered sets all exact
• observer sampling maximum: 0.5 ms
• 2 s resolve/paint gate passed

The browser observer revision only adds post-resolve Explorer-model polling. The activation and direct resolve path is byte-equivalent to the native trace. Earlier providerRegistered=false and empty model findings were observer-ordering false positives and are excluded.

Investigation

1. Reduce the remote filesystem request/response path to the smallest same-origin WebSocket/channel fixture that reproduces native latency with a fast Chromium oracle.
2. Attribute time across renderer enqueue, socket write/read, server channel handling, native event-loop wakeup, interop dispatch, and promise/microtask continuation.
3. Check whether the fixed delay applies to the first request only, every request, reconnects, cancellation, errors, and concurrent requests.
4. Fix the smallest generic WebScene owner contract. Keep Code OSS and its remote provider unchanged.

Acceptance

• A product-neutral browser/native oracle returns identical stat/read-directory results and error classes through the same request/response protocol.
• Cold and warm native p50/p95 are recorded against Chromium; the five-entry fixture completes resolve and first-child paint within 2 s.
• One logical provider request produces one bounded socket write and response; queue depth, queued bytes, tasks, DOM mutations, scene publications, and wakeups have explicit ceilings.
• Cancellation, disconnect/reconnect, denied/missing paths, malformed responses, and out-of-order concurrent responses settle once without stale delivery.
• A repeated lifecycle gate releases sockets, callbacks, promises, tasks, provider listeners, documents, and watcher handles; RSS/V8 heap growth is bounded.
• The unchanged Code OSS product trace preserves the exact selected URI, provider registration, five resolved/model/rendered children, and watcher readiness under the latency bounds.
• Directly related macOS/Linux native checks and the Chromium oracle pass before Qualify remote workspace bootstrap, Explorer contents, and watcher refresh #252 is requalified.

Current disposition — 18 September 2026

The implementation chain is complete: #297 closed its theme-continuation slice and the scheduler work from #287/#293/#289 landed through PR #347 as dbd7351a. Product-shaped direct evidence now keeps the 1.07 MiB protocol flush at 0.157 ms p95 / 0.274 ms max with bounded queues and flat V8 heap.

This issue requires no separate implementation. It remains open only for the same current-package #252 exact provider/root/first-child proof used to close #287, #293, and #289. If that run passes, close all four from the shared evidence; if it fails, attribute the new earliest boundary before opening another child.

[wieslawsoltes]

The first generic defect is now split as native subissue #284 with focused PR #285.

Direct evidence for that split:

• an observer-free baseline fails to finish the socket lifecycle before a single observation at 500 ms;
• PR Wake runtime for fair WebSocket delivery #285 completes 100 sequential cold/warm connect/echo/close cycles before that observation, while a MessagePort queue refills continuously;
• final direct result: cold 0.118 ms, p95 0.155 ms, at most 23 competing MessagePort deliveries, cancellation/reconnect exactly once, stable 1,027,564-byte V8 heap, and 45.7 MB max RSS;
• related worker/postMessage/idle-platform filters pass.

The correctly rebuilt and relinked unchanged Code OSS product trace shows #284 is necessary but not sufficient for this parent issue. Functional output remains exact—registered provider, selected URI equals the only workspace root, exact five resolved/model children, 5 rendered rows, 64 Explorer DOM nodes—but resolve still takes 7,641.1 ms and first paint 11,577.4 ms. Log: /private/tmp/vscode-252-product-navigation-280-correct.log.

Therefore #280 and #252 stay open. The remaining investigation must attribute time below the now-qualified socket wake/fairness boundary; PR #285 does not claim the product latency gate.

[wieslawsoltes]

Post-merge control on exact WebScene aa06172c rules out the native harness's 100 ms host-evaluation polling as the remaining delay.

The query-gated local observer stopped all host state evaluations and invalidations immediately after the first navigation handoff, then relied only on the in-page terminal console record. The unchanged Code OSS result was:

• host workspace-state polls during resolve: 0
• exact selected URI/workspace root: yes
• provider registered: yes
• exact resolved/model child set: 5
• rendered Explorer rows / DOM nodes: 5 / 64
• resolve: 8,055.1 ms
• first child paint: 12,034.7 ms
• observer sampling maximum: 51.43 ms
• peak child-process RSS: 801,800,192 bytes

This matches the original 8.14 s boundary, so observer polling is excluded. #284's merged socket queue/wakeup gate remains independently qualified (max 23 competing MessagePort deliveries and stable V8 heap), while the remaining delay stays under #280. Investigation-only local vscode-demo commit: a3ab610; product log: /private/tmp/vscode-252-product-navigation-280-no-host-poll.log.

[wieslawsoltes]

The one-shot, exact-package attribution trace on merged WebScene aa06172c identifies the remaining generic scheduler boundary and splits it to native subissue #287.

Inputs were AppScene 1420e227, unchanged Code OSS 645f29cc, Node 24.18.1, and local query-gated observer 74b3b94 atop validated no-host-poll observer a3ab610. The app/server process group was terminated immediately after the terminal workspace record. Log: /private/tmp/vscode-252-product-navigation-280-attribution.log.

Functional evidence remained exact:

• selected vscode-remote URI == only workspace root
• remote provider registered
• exact resolved/model children: .hidden.txt, readme-link, README.md, subdir/, unicodé.txt
• five rendered Explorer rows; 64 Explorer DOM nodes

Attribution:

• 151 native WebSocket events / 13,118,749 bytes; maximum queue depth 27
• receive → runtime dispatch: 25,322.5 ms aggregate, 3,563.26 ms maximum
• JS socket callbacks: 200.777 ms aggregate, 4.916 ms maximum
• post-callback microtask checkpoints: 1.890 ms aggregate, 1.100 ms maximum
• 146 FileReader reads / 13,115,590 bytes
• underlying Blob.arrayBuffer(): 1.532 ms aggregate, 0.041 ms maximum
• FileReader call → loadend: 658,518.7 ms aggregate across overlapping reads, 14,940.7 ms maximum
• first exact-root stat wave: about 5,416 ms; following readdir wave: about 2,299 ms
• sampled scene publications remained individually bounded; observed maximum 64.35 ms
• peak child-process RSS: 856,621,056 bytes

The byte counts align the native socket, Blob, and FileReader path. Blob copying, JS callbacks, and callback microtasks are small. The source-level boundary is task arbitration: ready Worker/MessagePort/WebSocket sources return before the runtime checks due timers, while FileReader schedules both its read start and terminal events with zero-delay timers. Continuous protocol traffic can therefore starve the timers required to consume its own responses.

#287 owns product-neutral fairness between async message sources and due timers, with direct native/browser, ordering, cancellation/reconnect, teardown, queue, scene, heap/RSS, and unchanged-product gates. #284 remains complete and is not reopened. #280 is reopened because #284 was necessary but did not satisfy this parent's product latency acceptance.

The instrumentation intentionally adds bounded observation and this run is attribution evidence, not a new performance qualification result. The clean no-host-poll 8,055.1 ms result remains the comparison baseline until #287 is fixed and the unchanged product is rerun.

[wieslawsoltes]

#287's focused direct candidate proves timer fairness against the Worker/MessagePort/WebSocket group, but the unchanged product rerun shows that source group is not the full remaining #280 owner.

On local 0f92cf47 rebased to WebScene main aa786c0e, the 256-frame FileReader gate records p95 0.119–0.198 ms and maximum 0.272–0.716 ms, exact bytes/event order, ≤20 competing port deliveries, 514/514 timers, ≤4,482 microtasks, 2 scene builds, stable heap, and 47.6 MB RSS. Baseline fails the same gate.

The exact AppScene 1420e227 / Code OSS 645f29cc / Node 24.18.1 product rerun remains correct but slow:

• exact selected/root URI, provider registration, five resolved/model children, five rows, 64 DOM nodes
• resolve 7,749.84 ms
• first child paint 11,788.09 ms
• sampling maximum 48.46 ms
• peak child-process RSS 860,160,000 bytes

Product log: /private/tmp/vscode-252-product-navigation-287-candidate.log. #287 remains local/unpushed and does not close #280. The next measurement must distinguish other runtime task sources and non-task phases before another fix.

[wieslawsoltes]

The unchanged-product candidate timeline moves the remaining parent boundary to existing Worker/MessagePort owner #81; no duplicate defect is opened.

From /private/tmp/vscode-252-product-navigation-287-candidate.log:

• workspace observer start (correlated): 1789655981628.9
• direct provider resolve start: 1789655985605.0
• remote extension host reported unresponsive: 1789655989676
• AgentHost:remote Connected: 1789655993265
• exact five-child resolve completes: 1789655993354.9 — about 90 ms after connection
• five Explorer rows paint: 1789655993417 — about 152 ms after connection

The extension-host WebSocket opened after 1,247 ms, but the AgentHost connection milestone took roughly another 16.6 seconds. Once it connected, provider resolution and paint completed immediately. #81 already owns unchanged Code OSS's browser extension-host iframe, Worker, transferred MessagePort, handshake, responsiveness, and lifecycle acceptance, with #288/PR #245 owning the active-port lifetime overlap.

Dependency order is now: #81 packaged handshake/latency (coordinated with #288 as needed) → rerun #280 direct provider bound → rerun #252 Explorer 2 s bound. #287 remains a valid focused generic timer/task-source fairness finding, but its local candidate is independently insufficient for this parent.

[wieslawsoltes]

The #81 phase trace refines this issue's upstream dependency. Local iframe/Worker/transferred-MessagePort startup completes in order, while the remote extension-host protocol takes 1,177 ms from connected transport to Ready and 4,379 ms from Ready to Initialized. That distinct owner is now #289 (native subissue of #81), separate from #288.

After the remote handshake, the separate AgentHost service connects and the exact five-child/five-row workspace result follows 99 ms later. Requalify this issue after #289: #289 → #280 → #252. Local #287 remains unpushed and is not sufficient.

[wieslawsoltes]

Packaged receiver-boundary trace on unchanged Code OSS 645f29cc, AppScene 1420e227, exact Node 24.18.1, and the current diagnostic package now separates the 4.2 s remote Ready → Initialized interval.

Second workspace document:

• remote transport connected → Ready: 1,288.17 ms
• Ready → next Promise microtask: 0.116 ms
• _createExtHostInitData() settle: 426.90 ms
• JSON + UTF-8 serialization: 8.61 ms for 1,071,424 bytes
• init-data send → remote Initialized: 3,788.40 ms
• total Ready → Initialized: 4,224.01 ms

Resource delivery remains fast: the iframe response was 0.899 ms / 6,786 bytes and the worker module response was 2.803 ms / 1,932,148 bytes. The exact selected URI/root, provider registration, five resolved/model children, five rendered rows, and 64 maximum Explorer DOM nodes all passed functionally. Peak app process-group RSS was 837,376 KiB. The bounded run terminated its complete process group and verification found no app/server/helper descendants.

The independent 20-cycle native product-neutral oracle is also fast (Ready p95 5.944 ms; Initialized p95 5.408 ms; socket dispatch p95 5 ms; FileReader p95 2.536 ms; Promise/microtask p95 0.0078 ms; serialization p95 0.213 ms). Chromium passes the same 43/43 contract (Ready and Initialized p95 1.7 ms). Therefore no generic WebScene implementation is justified from this evidence yet. The next trace must split the receiver side after the 1.07 MB init payload is sent: receipt/parse, init-data hydration, extension scan/activation, and Initialized response.

Retained evidence:

• product log: /private/tmp/vscode-252-product-handshake-289.log
• product log SHA-256: d85db2b31883b5f5f7e3a6747de96945c1810e792b0293a03df104a5dee0b761
• process/RSS summary: /private/tmp/vscode-252-product-handshake-289-process.txt
• native oracle: /private/tmp/webscene-289-baseline.log
• Chromium oracle: /private/tmp/webscene-289-chrome-baseline-verify/results.json
• query-gated local vscode-demo observer commit (not pushed): 10fc9aa

[wieslawsoltes]

Receiver-side instrumentation isolates the breach before Node parsing or extension initialization.

On the retained second workspace document:

• Node remote extension host sent Ready at 1789658968549
• WebScene browser received Ready at 1789658969571: 1,022 ms inbound delivery
• WebScene serialized and sent the 1,071,425-byte init message at 1789658969991
• Node remote extension host received that exact 1,071,425-byte message at 1789658973482: 3,491 ms outbound browser → Node delivery
• receiver UTF-8 decode: 0.133 ms
• receiver JSON parse: 3.589 ms
• total receiver hydrate/watchdog work before Initialized: 12.204 ms
• Node sent Initialized at 1789658973495
• WebScene browser received Initialized at 1789658973588: 93 ms return delivery

ExtensionHostMain construction begins only after Initialized is sent, so extension scanning/activation cannot own the Ready → Initialized breach. The exact root/provider/five resolved children/five model children/five rendered rows/64-node result still passes functionally. The 50 s bounded observer waited for the later constructor completion marker, then terminated the complete process group; no app/server/extension-host descendants remained. Peak process-group RSS was 843,184 KiB.

A size-matched control preserves the earlier fast baseline: the product-neutral native oracle sends a binary-compatible 1,071,424-byte payload for 20 cycles and reports Initialized p95 6.140 ms; Chromium passes 43/43 in 89 ms. The next reduced gate must add the actual Code OSS binary framing/compression and concurrent traffic/queue shape, retain enqueue → wire → server-receipt timing, and preserve this fast size-only control before any WebScene implementation.

Retained evidence:

• app log: /private/tmp/vscode-252-product-receiver-289.log (SHA-256 51d5b4d696b5474e2210a1f13851b39531443030927fa148f6705ffc79aed160)
• server/receiver log: /private/tmp/vscode-252-product-receiver-289-server.log (SHA-256 372b41c577260eb7787ceeaaca6c7f6655ced1259f4a4d4e9715e6280cf2e9db)
• process/RSS summary: /private/tmp/vscode-252-product-receiver-289-process.txt
• matched-size native control: /private/tmp/webscene-289-one-mib.log
• matched-size Chromium control: /private/tmp/webscene-289-chrome-one-mib-2/results.json
• local query-gated receiver observer commit (not pushed): da9db1a