TransportEof
The transport reached EOF with no orderly close.
Class in muse_code
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 as the durable-looking echo forbids, and every turn wait hung.
It carries no evidence fields, and that is the honest shape: 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,
host_exited latches the FIRST discharge, so a later exit
replays the EOF’s report rather than overwriting it with a richer one.
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 | Description |
|---|---|---|
kind |
Literal['transportEof'] |
The notification discriminator, always "transportEof". |
Source
clients/sdk-py/src/muse_code/facade/host_death.py:107