fix(stack): recreate containers whose published host port was taken before start

[jgoux]

TL;DR

stops a container service from failing to start when its published host port is taken between create and start.

whats broken?

containers publish with an engine-chosen host port (127.0.0.1::<port>). Podman picks that port at create by opening and closing a socket, and pasta only binds it at start. Anything that grabs the port in between, such as an outbound connection from another stack, fails the start with Listen failed for HOST TCP port …: Address in use.

now fixed by:

• pasta's "Address in use" is classified as a port-allocation failure, like Docker's "port is already allocated".
• a launch that fails with a port-allocation failure removes its container and creates a new one, which gets a new port, up to 3 attempts. The last failure is returned as before.

ref:

• seen on: fix(stack): keep Auth database and stack host connections alive #7080

[github-actions]

🤖 AI Review

Both independent reviews completed; Codex reported no findings. Code inspection confirms one minor resource-lifetime issue and two diagnostic nits. The tracing finding is narrowed to the verified missing attempt count; its claim that every existing retry uses the helper is false. No major or critical issues were verified. Tests were read but not executed.

Findings

Severity	Location	Category	Sources	Claim
🟡 MINOR	packages/stack/src/runtime/Container.ts:1129	resource-management	claude	Abandoned retry attempts retain their environment directories and cleanup finalizers until the caller's scope closes. A successful service launch after collisions therefore keeps up to two unnecessary environment files, potentially containing secrets, for the service session's lifetime.
⚪ NIT	packages/stack/src/runtime/Container.ts:1136	conventions	claude	The launch span records retry.attempt_count only after removal succeeds and another attempt is scheduled. First-attempt success, first-attempt terminal failure, and removal failure before the first retry omit the count.
⚪ NIT	packages/stack/src/runtime/Container.ts:1135	error-handling	claude	If removing a collided container fails, the retry branch replaces the removal failure with the original launch error without explicitly logging or preserving the cleanup failure, obscuring why retrying stopped.

Stats

Claude findings: 3 · Codex findings: 0 · Confirmed: 3 · Refuted: 0 · Uncertain: 0

---

Models: claude-opus-5-5 + gpt-6.1-sol · Trigger: auto · Workflow run

This review runs once per PR. A maintainer can request another with a /ai-review comment.