Repository navigation
Reuse fresh parser resources before speculative host loads #379
Description
Parent: #266. Related epics: #264, #227.
Proven gap
On exact WebScene main a759ff3a008e362708b6b281ebb7c2742921eb53, normal text-resource loading derives its persistent/process cache key from resource kind, resolved URL, initiator origin, and cookie representation. Parser speculative prefetch instead looks up the same cache using only resource kind and resolved URL.
That key mismatch bypasses an already-fresh admitted script or stylesheet before normal loading can consume it. The current native regression consequently performs duplicate host reads across engine generations (document and script bodies were not reused from the process resource cache and the related four-engine single-flight request-count failure). This directly affects repeated Markdown/webview parser resources after the Service Worker cache-continuity work in #376/#378.
Scope
- Derive speculative-prefetch cache lookups from the same origin/cookie-partitioned representation key as normal loading.
- Reuse only entries that are already fresh under the existing expiry metadata. Preserve existing validator revalidation and stale-fallback behavior for non-fresh entries.
- Keep resource kind, resolved URL, initiator origin, cookie, credentials, admission, and host callback boundaries unchanged and fail closed.
- Add a browser/WPT-derived freshness oracle plus native exact-key, validator, duplicate-read, 100-cycle latency/memory, and teardown gates.
Exclusions
No new filesystem or network authority; no CacheStorage durability or cross-origin sharing; no change to Service Worker registration, localResourceRoots, localhost mapping, CSP, AppScene, File System Access #248, consolidation #76, or vscode-demo.
Acceptance
- A fresh parser script/stylesheet cached under one origin/cookie representation is reused without another host read.
- A different origin or cookie representation never consumes that entry.
- Expired entries still carry validators to the host and consume a 304 result through the existing path.
- Browser and native results agree on fresh reuse versus validator revalidation.
- 100 repeated create/load/destroy cycles stay within p95 <= 100 ms for the cached resource step, <= 8 MiB retained V8 heap after warm-up, and <= 64 MiB RSS after teardown.
Activity
wieslawsoltes commentedon Sep 18, 2026
Owned from exact main
a759ff3a008e362708b6b281ebb7c2742921eb53onfeature/service-worker-cache-revalidation-266.Reproduction: parser speculative prefetch calls
read_resource_cachewithdigest(kind, resolved URL), while the normal loader writes and readsdigest(kind, resolved URL + initiator origin + cookie). A fresh admitted parser resource is therefore missed and re-read from the host. This matches the existing Linux sequential reuse and macOS four-engine single-flight request-count failures recorded under #266.This child owns only key parity for fresh speculative reuse plus validator/304, isolation, performance, memory, and teardown proof. Origin, cookie, resource kind, freshness, admission, credentials, host callbacks, and stale fallback remain authoritative. It adds no durable CacheStorage, cross-origin reuse, filesystem/network permission, or consumer-specific path.
Collision audit: the only open PR is consolidation #76, limited to compatibility documentation. #248 owns File System Access resolution. This slice owns the native resource cache/prefetch include, its focused native gate/filter, and a dedicated WPT-style freshness contract/profile; it excludes AppScene, CSS implementation, #76, #248, and vscode-demo.
wieslawsoltes commentedon Sep 18, 2026
Implemented and merged in #383 as
b5b51017ab1888ecdadbb638590afa645ee5f62a.Final scope and evidence:
Set-Cookie, uncacheable, origin-changing, and cookie-changing responses remain engine-private;No filesystem resolve, AppScene, CSS, consolidation, or vscode-demo paths changed.