WebKit does not return flow-control credit when a WebTransport stream finishes (bug 319818). A connection's receive window drains as bytes and streams arrive and never refills, so the session stalls near 16 MiB of cumulative stream data or 7,600 streams, whichever comes first. This page drives one connection at both lines and records where your browser stops.
Start with Normal use: one stream carrying a few MiB, a couple of hundred short streams, and a burst of datagrams, all well under both lines. It should finish green on every browser, Safari included, and proves the endpoint and your network before the two runs that cross a line. Chrome and Firefox finish those as well. A red bar there on Safari or iOS is the bug, and the number beside it is your device's line.
The endpoint is the same echo, on the library pin Safari accepts, with a
64 MiB session budget and a ten-minute lifetime, one session per address. Runs go through
https://echo.semantic-ui.com:4441/echo. Nothing is stored server-side.
A run that makes no progress for eight seconds is called stalled and the connection is closed. Datagrams are unreliable by design, so a few missing from that count is the network, not a stall.
The client's writes are accepted and the server echoes them, but the bytes stop arriving
because the browser stopped telling the server it may send more. Nothing errors. The
session's closed promise stays pending, keepalives keep the QUIC connection
alive, and every stream on it is dead. An application on top of this has no signal but its
own silence watchdog, which is why any long-lived WebTransport session on Safari needs one.
Datagrams are unaffected: they are exempt from stream flow control by design.