Object store connection failures

What the CLI reports when it cannot reach the fleet's object store, and what each report means. The object store itself is on Object store.

CLI connection failures

When the native HTTP transport reports that it could not establish a connection, the CLI classifies the failure as infra_down. It preserves the original cause chain and requested URL. The classification comes from the transport's error type, not from words in an exception or a command argument.

Object-store HTTP errors and registry snapshot reads carry this classification through database resolution, resolver commands and publisher host lookup. For a declared product and consumer, database resolution is a read-only way to observe that dependency:

stado database resolve "$PRODUCT" --consumer "$CONSUMER" --json

A connection failure is not an absent registry object, an HTTP authentication refusal or proof that the whole host is down. It says that the requested connection could not be established; the retained cause identifies what the transport observed. The failure uses the existing fleet failure code and retry exit policy. This classification adds neither a wait nor a retry loop.

The object API, the resolver and the local API all run in this machine's one Stado process, and a unit that exits at start is restarted by its supervisor without telling anyone. So every stado command that fails with infra_down also reads this machine's Stado unit, and when its supervisor holds it loaded with no running process and a nonzero last exit, prints after the error line:

this machine's com.wisent.stado runs no process: its last run exited <code> and its supervisor has started it <runs> time(s); <log file> last said: <line>; <error log file> last said: <line> (`stado service unit logs com.wisent.stado --host <this host>` reads more)

Each named file's last line holding anything is said, stdout's then stderr's, a file with no such line left out: the two files carry no common clock, so neither is taken for the newer. On a systemd host one journal holds both streams, so one clause names journalctl -u <unit> and its last line. It is the window stado service status shows for a failed unit. With --json the same sentence is the error document's host_unit field, null when the unit runs, last exited cleanly or is not loaded on this machine. A read of the unit that fails is said instead, whether this machine's Stado unit is failing could not be read: <cause>; it is never taken for a running unit. Stado Desktop shows the line in the operation's complete receipt, which carries the command's standard error.

Source: this website