mirror of
https://github.com/microsoft/vscode.git
synced 2026-08-16 19:24:27 +01:00
17d3b86b93
Codex extension surfaced a renderer forced exit after hitting EMFILE on Linux when a webview issued very large number of concurrent local resource fetches. Diagnosis - Codex extension can trigger roughly 625 concurrent webview resource requests. - Webview resource loading currently forwards each request to the host and begins transferring the returned body immediately. - Disk reads are chunked at 256 KiB, and Mojo uses shared-memory FDs for payloads above 64 KiB, so each in-flight resource body can consume file descriptors in the renderer while it is being streamed. - The sandboxed renderer runs with RLIMIT_NOFILE=1024 on Linux. - This is not specific to codex extensionn, any extension with enough concurrent resource bodies can accumulate to exhaust the renderer FD budget. This makes the problem specifically about the number of simultaneously active host-backed response bodies. A naive limiter around WebviewElement.loadResource() would not address the root cause because loadResource() returns as soon as the stream is transferred, while the FD pressure persists for the lifetime of the stream in the renderer. Introduce a service-worker-side global concurrency limit for host-backed webview resource response bodies. - Add a global limit of 32 active host-backed resource bodies in the webview service worker. - Acquire a permit before creating/posting the load-resource request so time spent waiting for a slot does not consume the existing 30 second RequestStore timeout. - Hold the permit for the full lifetime of the returned ReadableStream, and release it only when the stream reaches EOF, errors, or is cancelled. - Release exactly once on all non-stream results and on every early/error path, including timeout handling. - Preserve existing range request behavior, ETag/304 handling, CacheStorage behavior, Safari fallback streaming, and cancellation semantics. - For cacheable responses, keep the permit until both source transfer and the associated cache write complete, without delaying delivery of the response back to the webview. - Bump the service worker version and WebviewElement expected version together so clients pick up the updated worker. Tests - Add an API integration regression test that creates a webview, materializes many local resources, fetches them concurrently from inside the webview, and verifies the webview stays alive and all loads complete. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>