Pinned at: develop @ 31d6fb97, consuming @supabase/stack via createStack() from Node.
The stack computes exact Docker cleanup targets at build time (CleanupTargets — the deterministic container names) and the daemon path persists them (StackMetadataPersistence.fromStateManager → stack.json) precisely so crash recovery can docker rm -f the exact set after the daemon dies. That's the right design — but it's daemon-only: the library/foreground layer wires StackMetadataPersistence.noop (layers.ts), and StackHandle exposes no cleanup targets.
An application embedding createStack() in its own supervisor has the identical crash-recovery need: if the host process is SIGKILLed hard enough that the detached per-service supervisors also die before their cleanup runs, the embedder must remove leftover containers on its next start — and today the only way to know their names is to re-derive the internal supabase-<service>-<apiPort> convention (StackBuilder's dockerContainerName), i.e. couple to an implementation detail that can drift.
Request: expose the computed cleanup targets read-only on the public handle (and/or StackInfo), so embedders can persist the same exact-targets record the daemon path already relies on. The data exists at handle-construction time; this is surfacing, not new machinery.
(For context: the per-service supervisors' orphan cleanup is excellent — in our testing it reaped containers within seconds of host death. This request is only about the residual case where the supervisors themselves are killed.)
Pinned at:
develop@31d6fb97, consuming@supabase/stackviacreateStack()from Node.The stack computes exact Docker cleanup targets at build time (
CleanupTargets— the deterministic container names) and the daemon path persists them (StackMetadataPersistence.fromStateManager→stack.json) precisely so crash recovery candocker rm -fthe exact set after the daemon dies. That's the right design — but it's daemon-only: the library/foreground layer wiresStackMetadataPersistence.noop(layers.ts), andStackHandleexposes no cleanup targets.An application embedding
createStack()in its own supervisor has the identical crash-recovery need: if the host process is SIGKILLed hard enough that the detached per-service supervisors also die before their cleanup runs, the embedder must remove leftover containers on its next start — and today the only way to know their names is to re-derive the internalsupabase-<service>-<apiPort>convention (StackBuilder'sdockerContainerName), i.e. couple to an implementation detail that can drift.Request: expose the computed cleanup targets read-only on the public handle (and/or
StackInfo), so embedders can persist the same exact-targets record the daemon path already relies on. The data exists at handle-construction time; this is surfacing, not new machinery.(For context: the per-service supervisors' orphan cleanup is excellent — in our testing it reaped containers within seconds of host death. This request is only about the residual case where the supervisors themselves are killed.)