Repository navigation
silkd: spawn failures are kind internal, so a wrong argv or cwd becomes a 502 on the buffered exec #145
Description
silkd/src/exec.rs answers a failed cmd.spawn() with {"kind":"internal","message":"spawn: No such file or directory (os error 2)"}. That is the shape a caller gets for a binary that is not in the flavor image, a cwd that does not exist, or a non-executable file — ordinary client mistakes.
POST /v1/sandboxes/{id}/exec maps every silkd error kind other than bad_request to 502, so {"argv":["pytest","-q"]} on a node:24.04 sandbox is reported as an infrastructure failure. A proxy or SDK that retries 5xx retries a request that can never succeed, and the caller cannot tell it from a dead guest agent except by reading the message text. Same class as #74 (fs.pull reporting Internal instead of NotFound).
Fix: classify the spawn errors that are the caller's (ENOENT, ENOTDIR, EACCES) as bad_request — or a dedicated kind — at the spawn site; the handler's existing bad_request → 400 arm then covers it, and Run in both SDKs surfaces a typed error. This changes a wire-visible kind, so grep the Go and Python SDKs and their tests for code that matches internal on spawn failures before flipping it.
Refs: silkd/src/exec.rs (cmd.spawn() error arm), sandboxd/server/exec.go (silkd error mapping).
Activity
CMGS commentedon Sep 14, 2026
A sibling landed in #168 that shows the shape:
session_createnow refuses an env name bash cannot export by returningio::ErrorKind::InvalidInputfromsilkd/src/session.rs, andserver.rsmaps that kind tobad_request. The spawn arm inexec.rscan routeENOENT/ENOTDIR/EACCESthrough the same mapping instead of a new kind; the SDK check for code matchinginternalon spawn failures still applies before the kind changes.