Sylvain Duchesne
dbd99738f0
La doctrine disait que la suite applicative ne peut pas être mesurée sur une machine dont le réseau bouge. Elle vient de passer 27/27 quatre fois d'affilée sous exactement ce bruit. Ce qui tranche n'est donc pas l'état de la machine mais la FORME de l'échec — un délai nommé sur une opération broker désigne le transport, une assertion qui rend une valeur inattendue désigne le code — et la répétition. Et la feuille sur le règlement de l'identité décrivait encore la session comme un thunk fourni par l'application. Elle appartient désormais au paquet, dont le wrapper init() capture l'événement : plus aucune application ne peut la câbler de travers, ce qui était pourtant la cause exacte de la régression racontée juste au-dessus. Dette de doc soldée.
2.7 KiB
type, summary, last_checked
| type | summary | last_checked |
|---|---|---|
| caveat | Chromium's control pipe drops without Playwright emitting close or disconnected, so a run dies mid-flight — it looks like a product defect and is not one | 2026-08-11 |
A run can die from a dropped pipe, and it is not the product
Chromium's devtools pipe sometimes drops mid-run. It logs a terminated-pipe message and exits cleanly, and Playwright emits neither close nor disconnected — observed four times out of four. From the client's side the browser simply stops answering.
Before waits were bounded this was fatal in a specific way: the suite blocked in its own teardown, so it printed neither its summary nor the failure already on its way out. Hours went into diagnosing silence. Every wait is now bounded and names what it was waiting for, so a lost browser costs seconds and a report.
How to recognize it. The run dies without a coherent failure, or several unrelated interactions time out at once, or the summary is missing entirely. If the suite reports a named deadline on a browser operation rather than a failed assertion, suspect the transport before suspecting the code.
It is not ours to fix. It is not caused by how a child process is spawned, nor by a leftover holding the profile, nor by overlapping launches — all three were probed and ruled out. It looks like Playwright losing its file descriptors without telling its client. Worth reporting upstream.
The host can be the cause too
A machine that reconfigures its network — a container in a crash-restart loop cycling its virtual interface, for instance — makes the applicative suite unreliable. The browser answers with a network-changed error, broker sockets fail, and every failure looks like a different product bug.
This has happened here: seven failures out of ten runs in one afternoon, all transport, none product. The check costs seconds — watch for repeated link events, and look for a container restarting.
But do not conclude the suite is unmeasurable: under that same churn it also ran green four times in a row. A red run under a moving network proves nothing, and neither does a green one. What decides is the SHAPE of the failure — a named deadline on a browser or broker operation points at the transport, a failed assertion carrying an unexpected value points at the code — and repetition: three consecutive green runs, or a failure that reproduces.
The discipline that follows: a suite that fails for transport reasons has measured nothing. Do not read it as a red baseline, do not chase it as a regression, and do not commit against it. Re-run it — and if the environment is known to be moving, say so alongside the result instead of letting a single run stand as the verdict.