The pre-up devpod status call costs 0.43-0.74s on every launch

[blooop]

Question

Can the pre-up devpod status call be avoided, cached, or answered more
cheaply?

Every launch pays it, warm ones included: 0.43-0.74s measured across runs. On
a warm launch that is the whole overhead outside the single ssh trip — a 2.7-3.5s
launch of which ~20% is asking devpod a question about state.

The neighbouring call has already been dealt with, which is the reason to think
this one is tractable: devpod context options is disk-cached, keyed so that
the cache expires when devpod's own config file changes rather than on a TTL
alone (context_options in clients/devpod.rs and the flow that caches it) —
which is why a warm launch shows no devpod context span at all, only devpod status. There is a worked pattern in this repo for exactly this shape of
problem, and a second one in the tool-verdict cache, which keys off the mtime of
devpod's workspace_result.json.

What makes this harder than the context cache, and what the answer must handle:

• Staleness here is not cosmetic. status is what decides warm versus cold.
  A stale Running sends a launch down the fast-attach path at a container that
  is gone; the cost of being wrong is a failed launch, not a slow one. Any cache
  needs a key that cannot silently agree — the same bar
  #158 applied when it rejected
  an mtime+size key under principle 3.
• docker inspect answers the same question in ~0.02s on the docker
  provider, which is 20-35x cheaper — but it is provider-specific, so it lands in
  the same fast-path-versus-one-mechanism argument as the sibling tickets. Decide
  it consistently with them.
• Or the call may be removable rather than cacheable. Ask whether the warm
  path needs a separate status at all, or whether the information is already
  available from state devpod has written to disk, or recoverable from the attach
  attempt failing cleanly. A launch that just tries and falls back may be both
  faster and more honest than one that asks first — or it may be worse, if the
  fallback is expensive or the failure is ambiguous.
• ContainerState is already a total sum with an Unknown(String) arm for a
  word this build has not heard of; whatever answers the question must keep that
  property rather than collapsing it to a boolean.

Where these numbers come from

All figures below were measured on 2026-08-24 against the Rust build
(rust/target/release/dl, dl 0.13.0), driven from inside this repo's own
devcontainer (nested docker-in-docker, devpod 0.26.1, docker 29.7.2, 8 CPUs).
DEVPOD_HOME, DEVPOD_SSH_CONFIG and XDG_CACHE_HOME were scoped to a scratch
directory; the target was blooop/dotfiles with a warm image and a warm bare
clone cache.

Caveat, and it is not small: nested DinD is not the host. Absolute seconds
here run higher than a host launch, and this is not the CI trend point
#292 is about. What transfers
is the ratios and the floors — the pieces are A/B'd against each other in one
environment. The host cross-check is that README's own host medians (warm
2.176s, cold-recreate 15.899s) sit close to what was measured here (warm
2.7-3.5s, cold 13.1-15.5s).

[blooop]

breadcrumb: there is no key, because the fact is not written down. Measured twice on
the #388 rig (devpod 0.26.1, scratch DEVPOD_HOME, a devcontainers/base:ubuntu
workspace so the container is not the variable), snapshotting
find $DEVPOD_HOME -type f -printf '%T@ %s %p' either side of each transition:

transition	what moves under $DEVPOD_HOME
devpod stop <ws>	agent/contexts/<ctx>/workspaces/<id>/workspace.json mtime, nothing else
docker stop <cid> (reboot, manual stop, OOM, daemon restart)	nothing — byte-identical, mtimes included

workspace_result.json — verdict_cache's anchor, and the only key in this repo that
cannot silently agree — does not move on either. A status marker keyed on it reads
Running for a container that stopped ten minutes ago, which is the exact failure this
ticket names. verdict_cache answers identity and identity is on disk;
context_options is keyed on devpod's config file and that file moves when the answer
does. Liveness is a property of a running process and has no file behind it.

[blooop]

breadcrumb: "just try the attach and fall back" has nothing to fall back from.
devpod ssh <ws> --command <cmd> on a Stopped workspace does not fail — it starts
the container and runs the command, exit 0. Reproduced twice: 4.04s and 4.13s against
1.97-2.37s on a running one, same container id, devpod's own setting up container on
stderr. devpod ssh --help on 0.26.1 has no flag that would refuse (--start-services
is port forwarding and credential helpers, not the container).

So the attempt is an implicit up performed by devpod, outside everything
up_under_stage exists to do: no launch lock, no DEVLAUNCH_WORKSPACE_ID, no staged
GH_TOKEN in the up args, and no PassOccasion::AfterUp pass — which that function's
own comment says must run after any start, because the restart rebuilds the UTS
namespace and the hostname stage has to run again. is_running is the only thing
standing between a user and an under-provisioned container reported as a warm attach.

[blooop]

breadcrumb: where the 0.57s goes, which is the fact #390 needs. devpod --help
(bare CLI init) is 0.048s and docker inspect -f '{{.State.Status}}' is 0.018s
(n=8), so neither startup nor the question accounts for devpod status's 0.569s.
devpod status --debug shows the rest: devpod answers the docker provider's status by
re-invoking its own binary as the provider's status command with an encoded
workspace info, which decodes it, resolves the context, creates the agent workspace
directory, resolves the content folder, and only then runs docker inspect. The floor
is provider indirection, ~0.52s of it, all local. Also measured for the record:
devpod list --output json 0.404s and carries no state field (as Workspace's doc
comment already says), so there is no cheaper devpod subcommand that answers this.

[blooop]

agent-decided (3):

The answer

The call stays, and stays a live ask on every launch: not cached, not replaced by a
try-and-fall-back, not removed. What is removable is one extra ask — dl <ws> dotfiles
asks devpod for state it has already been told — and that trip is the whole build slice.

Reproduced first, on the rig #388-#392 were measured on (devpod 0.26.1, docker 29.7.2,
scratch DEVPOD_HOME/DEVPOD_SSH_CONFIG/XDG_CACHE_HOME, and a
devcontainers/base:ubuntu workspace rather than a real repo, so the container is not
the variable): devpod status <ws> --output json median 0.569s, n=8, 0.545-0.677.
The ticket's 0.43-0.74s holds.

Option 1 — cache the answer. Refused, and the measurement is what refuses it.

There is no key, because the fact is not written down anywhere. Measured twice, cleanly:
devpod stop <ws> moves one mtime (agent/contexts/<ctx>/workspaces/<id>/workspace.json)
and nothing else; docker stop <cid> — the reboot, manual-stop, OOM and daemon-restart
case — leaves $DEVPOD_HOME byte-identical, mtimes included. workspace_result.json
does not move on either. See the first breadcrumb for the table.

That is the end of it: a marker keyed on the one anchor this repo has would read Running
for a container that stopped ten minutes ago, and #393's own framing says why that is
fatal rather than cosmetic — the fast-attach path launches at a container that is gone.
Same bar #158 applied to mtime+size,
same answer.

The two existing caches are precedent against a third here, each for its own reason:

• context_options is TTL plus "older than devpod's config file". It works because
  the cached answer is derived from a file, and that file's mtime moves whenever the
  answer changes (devpod context use, setting an option). One stat, no round trip.
• verdict_cache works because its question is is this the same container, a
  different container means a completed up, and a completed up rewrites
  workspace_result.json. It answers identity, and identity is on disk.

Liveness is a property of a running process. Neither mechanism transfers, and a TTL alone
is the same refusal one notch weaker — this map's own Notes already say the context cache
expires on the config file "rather than on a TTL alone".

Option 2 — try the attach and fall back. Refused, and this is the finding.

devpod ssh <ws> --command <cmd> on a Stopped workspace does not fail. It starts the
container and runs the command, exit 0 — 4.04s and 4.13s against 1.97-2.37s on a running
one, reproduced twice, with devpod's own setting up container on stderr. There is no
flag on 0.26.1 that would refuse. So the probe is an implicit up, done by devpod
outside the launch lock, the DEVLAUNCH_WORKSPACE_ID stamp, the staged GH_TOKEN up args
and the PassOccasion::AfterUp pass that up_under_stage's own comment says must run
after any start. Second breadcrumb has it in full. Trying first does not ask a cheaper
question; it hands devpod a decision dl is holding.

The refusal survives devpod growing the flag, and this is the part that belongs to
principle 3 rather than to a measurement: SshOutcome::DevpodFailed is one arm covering
"devpod never ran the remote program or lost it partway". A fallback that retries on
that arm re-runs the user's -- <cmd> when it may already have run, and nothing in
devpod's stderr protocol distinguishes the two. Try-first needs a state devpod cannot
represent, which is a stronger objection than the side effect.

Option 3 — drop the question, always up. Refused on arithmetic.

devpod up on an already-Running workspace: 2.12s / 2.23s / 2.12s, against status's
0.57s. Four times the cost, and it rewrites workspace_result.json every launch, which
moves verdict_cache's anchor and re-costs the setup pass forever. Worse on both axes.

Option 4 — the provider-specific answer. Deferred to #390, and handed one fact.

docker inspect -f '{{.State.Status}}' is 0.018s against 0.569s, 32x, and the third
breadcrumb decomposes where the rest goes: not CLI startup (devpod --help is 0.048s) but
devpod re-invoking its own binary as the docker provider's status command. Same argument
as #390's docker exec, same provider gate, same ssh path underneath, so it is #390's
call and this ticket does not pre-empt it.

One constraint travels with it, and it is a constraint on the type, so it composes with
either outcome: a provider fast path must be an implementation of devpod::status,
behind the existing signature, returning Result<ContainerState, StatusUnreadable> with
all five arms live — an unrecognised docker state word arriving as Unknown(String), not
as an error and not as a false. Not a second question with a second answer type. A
fast path that cannot answer fails into StatusUnreadable or falls through to devpod, and
no consumer learns which answered. A caller that could tell would be
#151's two-predicate drift in a new
place.

What is removed: the duplicate ask in dl <ws> dotfiles

run_attach and run_up_verb read liveness out of the Placement stage two built.
up_under_stage re-asks, deliberately and with the reason written down — it is on the
other side of a wait for a sibling, and the sibling is the likely author of a create that
died in its hooks. run_dotfiles re-asks for no reason: flows/launch.rs:2843 calls
lifecycle::workspace_state for a workspace whose state is sitting in placement. A
second devpod status in one command, 0.57s, for a fact the command already holds — and
a pre-up status call, since what it gates is an up.

placement.is_running() gives the same answer in all three arms. Known carries the
state. Creating and Listed are false, which is both the right answer and the one a
second status produces anyway (devpod refuses an id it does not know; a Listed
workspace is one status could not describe). The cost is that dotfiles acts on an
observation ~0.6s older, which is the window every warm launch already has between its
status and its attach.

The type shape

ContainerState is untouched: five arms, Unknown(String) kept, is_running the one
projection. Nothing is added beside it — no cached_at, no stale: bool, no
Option<ContainerState>. A freshness tag parallel to the value is the sentinel that
KnownWorkspace and Placement were built to delete, and the one
#171 spent a ticket removing, whose
None meant both "nothing to lose" and "could not tell".

The invariant this ticket decides is not about ContainerState's arms. It is: within one
launch there is exactly one observation of container liveness, and it is an observation
rather than a memory. The representation that enforces it already exists —
Placement::Known { workspace_id, state }, the sum built so that "is this launch warm" is
a question about one value instead of a conjunction over two. The defect found is a call
site that went around it. So: no new type, and every reader of liveness reads the
Placement it was given.

The arm deliberately not created, now or under #390, is Remembered. Its absence is the
decision.

The test

A structural pin, in the idiom this map already has three of (spawn counts, fetch counts,
lock cycles): the exact count of devpod status argv per launch shape, at the
recorded-call seam flows/launch.rs's unit tests and rust/dl/tests/launch.rs already
assert on.

shape	devpod status calls
warm attach (dl <ws>, dl <ws> -- cmd)	1
dl <ws> up, workspace running	1
cold	1 (2 in the #88 recorded-id case)
warm attach that waited out a sibling	2
dl <ws> dotfiles, warm	1 (2 today — the red test)

The pin's real job is the row not in the table: 0 is a failure for every warm shape.
That is what makes "the answer is always a live ask" CI-effective instead of a paragraph,
and it is what a future cache trips over. #145's
lesson applies — write it so it can fail, and prove it does by reintroducing the second
dotfiles call.

No test for the three refusals. Per #158's precedent they carry falsification
conditions, and each is one command:

• Reopen the cache if any file under $DEVPOD_HOME starts moving when a container
  stops without devpod's involvement. Check: docker stop the container, diff a
  find -printf '%T@ %s %p' snapshot either side.
• Reopen try-first if devpod ssh gains a flag that refuses to start a stopped
  workspace. Check: devpod ssh --help.

What it costs

Every warm launch keeps paying ~0.57s to ask a question whose answer nothing on the host
writes down, and the only route to a cheaper one runs through #390's provider-specific
reach. dl <ws> dotfiles gets 0.57s back. That is the whole of the win here, and it is
not on the warm path — said plainly because this map states its destination in
measurements and this ticket does not move the headline number.

Build slice

dl <ws> dotfiles reads the state it was given. Small, no new module, no cache, no
type change.

• flows/launch.rs::run_dotfiles — replace the lifecycle::workspace_state(...) /
  is_ok_and(ContainerState::is_running) pair with placement.is_running(). The
  Creating/Known/Listed match below it is untouched.
• Pin devpod status counts per launch shape at the existing recorded-call seam, per the
  table above, with dotfiles-warm = 1 as the red test and 0 as a failure for every warm
  shape.
• CHANGELOG: one devpod round trip off dl <ws> dotfiles.

[blooop]

breadcrumb: the deferral is closed — see #390's resolution. The provider fast path is refused, and the type constraint this ticket handed down is what refuses it rather than what would have enabled it. Two reasons, both measured on #390's thread: devpod 0.26.1's docker driver puts no devpod.* workspace label on the container, so dl cannot even name it without re-deriving devpod's workspace-UID scheme or parsing devpod's private workspace.json; and honouring "all five arms live, no consumer learns which answered" means dl carrying its own copy of devpod's docker-state-to-devpod-word mapping — including deciding when docker's answer is Busy, a state about devpod's activity rather than the container's — with the disagreement invisible by construction. devpod status stays the only implementation, exactly as this ticket left it.