Readiness probes

Coppice can now hold POST /sandboxes open until a sandbox is actually usable by the caller’s definition: a TCP port accepts connections, or a shell command exits zero inside the sandbox.

The route accepts a per-create override:

{
  "templateID": "python",
  "readinessProbe": {
    "type": "tcp",
    "port": 8080,
    "timeoutMs": 30000,
    "intervalMs": 250
  }
}

Shell probes are also supported. A string command is run through /bin/sh -lc; an array is passed as argv:

{
  "templateID": "worker",
  "readiness_probe": {
    "type": "shell",
    "command": "test -S /tmp/app.sock",
    "timeout_ms": 30000
  }
}

Template authors can bake the same JSON into <template-root>/READINESS.json for jail templates, or next to a bhyve image as <name>.img.READINESS.json. A create-time field overrides the template default. Invalid probe specs are rejected before create starts; probe failures tear the sandbox back down and return 503, so callers do not receive a sandbox id for a half-ready instance.

Implementation notes

• TCP probes connect from the gateway to the sandbox’s guest IPv4 address. Backends that do not expose sandboxIP cannot use TCP readiness.
• Shell probes dispatch through the owning backend’s exec implementation: jexec for VNET jails and SSH for bhyve pool guests.
• Timeouts are bounded to five minutes so a bad readiness spec cannot pin an HTTP worker forever.
• POST /snapshots/:id/fork accepts the same readinessProbe override and otherwise inherits the source template’s default.

Receipts: unit coverage in e2b-compat/src/readiness.rs validates JSON shape, defaulting, and field rejection. The create/fork path compiles through the focused gateway tests; live host verification is blocked until honor’s current VNET ifconfig ... vnet D-state wedge is cleared.