TransportEof
The transport reached EOF with no orderly close.
names TWO notifications of a host death — “process exit or transport EOF” — and only the exit half was implementable while nothing in this SDK owned the close. A host that closes stdout while still hung emits no exit on the timescale that matters, so without this arm its session never discharged: every pending command sat in the set as the durable-looking echo forbids, and every turn wait hung.
It carries no evidence fields, and that is the honest shape rather than a
gap: EOF IS the whole observation. The stderr tail and the row belong
to the process boundary, which has not reported yet — and when it does,
Session.hostExited latches the FIRST discharge, so a later exit replays the
EOF’s report rather than overwriting it with a richer one. Whoever owns the
process still has MuseServeChild.stderrTail and its exit promise.
ORDERLINESS IS NOT DECIDABLE HERE. Connection is duplex-generic and a
transport cannot tell a peer’s hang-up from its own shutdown, so the layer
that KNOWS whether the close was its own is the one that builds this:
MuseClient, which owns both close() and the connection.
Properties
Section titled “Properties”| Property | Type | Stability | Presence | Description |
|---|---|---|---|---|
kind |
"transportEof" |
required |
Source
clients/sdk-ts/src/facade/host-death.ts:95
{ "kind": "Interface", "canonicalPath": "TransportEof"}