docs(smoke): retract the #2132 mechanism claim; state that it is unknown

An isolated repro of the mechanism I described — a server writing three
SSE frames then going silent with the connection held open, read via
fetch + getReader — delivers every frame in all three engines, WebKit
included. So 'the SSE stream's last message is not delivered' is not a
supported description of the failure.

The keep-alive experiment that appeared to confirm it was one
observation, and the failure is not even stable in shape: two consecutive
webkit runs failed at different stages (ready wait vs connect wait),
which a deterministic buffering bug would not do.

What is unchanged: the App smokes really do fail under Playwright's
WebKit, which is why the engine stays out of the matrix; that reason
never depended on the mechanism. The parseSSE cross-chunk defect also
stands, being read off the code rather than inferred from an experiment.

No behavior change.

Signed-off-by: cliffhall <cliff@futurescale.com>
This commit is contained in:
cliffhall 2026-08-25 23:02:43 -04:00
commit d493b232b3

View file

@ -46,10 +46,11 @@
* `SMOKE_BROWSER` picks the engine (`chromium` — the default — `firefox`, or
* `webkit`). CI gates **Chromium** (in the `build` job's `npm run smoke`) and
* **Firefox** (in the `Sandbox smokes` matrix job); WebKit runs here but is not
* gated yet — it fails on #2132, where the SSE stream's last message is not
* delivered under Playwright's WebKit. That has NOT been reproduced in real
* Safari (an MCP App opens there fine), so treat it as a property of that
* build, not as a browser bug, until someone shows otherwise (#2086).
* gated yet — it fails on #2132 under Playwright's WebKit, by a mechanism that
* is NOT yet identified (the first diagnosis was retracted when an isolated
* repro did not reproduce it, and the failure stage varies between runs). It has
* NOT been reproduced in real Safari, so treat it as a property of that build
* rather than a browser bug until someone shows otherwise (#2086).
*
* This smoke is one of the two places the
* MCP Apps sandbox is genuinely exercised, and the sandbox is built out of the