Summary
When sprite file push targets a sprite name that does not exist, the CLI reports a filesystem error about the remote parent directory rather than a sprite-not-found error. This sent a production incident investigation down a long false trail (we probed base-image layout, boot races, and suspend behavior before discovering the target sprite had been destroyed by our own janitor process).
Repro (CLI on linux/amd64, authed)
$ echo probe > /tmp/probe.txt
$ sprite file push -s some-name-that-never-existed /tmp/probe.txt /home/sprite/x.tar
Error: directory /home/sprite does not exist
$ echo $?
1
Expected: something like Error: sprite "some-name-that-never-existed" not found (and ideally a distinct exit code from real remote-filesystem errors).
Actual: Error: directory /home/sprite does not exist — indistinguishable from the legitimate remote-parent-missing case (e.g. pushing to /tmp/..., which genuinely fails on a fresh sprite because tmpfs mounts after the parent-dir check — a quirk we design around).
Why it matters
We (collabd) run file transfers against sprites as part of a two-box sandbox pipeline and persist the CLI's stderr as the failure detail for triage. With this error shape, "the box was destroyed/never existed" and "the destination directory is missing on a live box" are the same string, so automated retry/recreate logic cannot distinguish a recoverable orchestration race from a real path bug.
Related earlier reports from the same integration: #201 (host-enforced --max-size for file pull), #202 (exec stdout byte drops on large streams).
Summary
When
sprite file pushtargets a sprite name that does not exist, the CLI reports a filesystem error about the remote parent directory rather than a sprite-not-found error. This sent a production incident investigation down a long false trail (we probed base-image layout, boot races, and suspend behavior before discovering the target sprite had been destroyed by our own janitor process).Repro (CLI on linux/amd64, authed)
Expected: something like
Error: sprite "some-name-that-never-existed" not found(and ideally a distinct exit code from real remote-filesystem errors).Actual:
Error: directory /home/sprite does not exist— indistinguishable from the legitimate remote-parent-missing case (e.g. pushing to/tmp/..., which genuinely fails on a fresh sprite because tmpfs mounts after the parent-dir check — a quirk we design around).Why it matters
We (collabd) run file transfers against sprites as part of a two-box sandbox pipeline and persist the CLI's stderr as the failure detail for triage. With this error shape, "the box was destroyed/never existed" and "the destination directory is missing on a live box" are the same string, so automated retry/recreate logic cannot distinguish a recoverable orchestration race from a real path bug.
Related earlier reports from the same integration: #201 (host-enforced
--max-sizeforfile pull), #202 (execstdout byte drops on large streams).