fix(infra): a removed worktree leaves its postgres container running, and two of them break every checkout

[janlauber]

Split out of #2105 — a different mechanism, same root cause: git worktree remove runs no hook.

What happens

A worktree that ran make infra starts its own compose project. Removing the worktree leaves the container running, and scripts/dev-env.sh's pg_container refuses as soon as it finds more than one:

dev-env.sh: no single postgres container to use — run `make infra` (in any
checkout; they share one server), or set WATTROOM_PG_CONTAINER when several
are running

That is not a per-worktree failure. It breaks make dev-server, make test and now make worktree-gc for every checkout on the machine, including the main tree, until someone sets WATTROOM_PG_CONTAINER or finds the stray container.

Right now

mic-camera-selection-ui-70d898-postgres-1   5432/tcp                     <- worktree removed 2026-09-10
blissful-tesla-682eac-postgres-1            0.0.0.0:5432->5432/tcp

The first belongs to a worktree that no longer exists. It publishes no port, so nothing can reach it — but it is enough to make every make target refuse. It also holds wattroom_wt_mic_camera_selection_ui_70d898_8351, which means the stranded databases from #2105 are spread across two servers rather than one.

The confusing part, worth writing down

Only make breaks. A bare go test with a DSN pointing at localhost:5432 keeps working, because exactly one of the containers publishes the port. So the symptom is "make stopped working but my tests pass", which points at the Makefile rather than at docker.

What to do

worktree-gc (#2098) is the natural home: bring the worktree's compose project down before removing the directory, for the same reason it now drops the databases first — afterwards there is no docker-compose.yml path to address the project by.

Whether it should also offer to stop a container whose worktree is already gone is the open question. The name embeds the worktree's directory, so matching is possible, but the same caution as #2105's stranded databases applies: another clone on the same machine looks identical from here. Reporting it and printing the docker rm -f may be the whole answer.

[janlauber]

The specific container has since gone — only blissful-tesla-682eac-postgres-1 is running now, so dev-env.sh resolves cleanly again and make worktree-gc works from the main tree.

That clears the symptom, not the mechanism: git worktree remove still runs no hook, so the next worktree that ran make infra and then got removed leaves the same stray container, and pg_container refuses for every checkout again the moment there are two.

Worth noting what it leaves behind either way — wattroom_wt_mic_camera_selection_ui_70d898_8351 was in that container, so it went with it. Ten stranded databases remain in the surviving server, all belonging to worktrees that no longer exist:

wattroom_wt_autonomous_issues_prs_9d0835_cc1a
wattroom_wt_blissful_tesla_682eac_5537
wattroom_wt_continuous_issue_triage_16a1b4_0c7e
wattroom_wt_continuous_issue_triage_40ddf1_2baf
wattroom_wt_continuous_issue_triage_95332b_2bc8
wattroom_wt_jukebox_ux_redesign_5a8c81_ddee
wattroom_wt_legal_surfaces_fe6d
wattroom_wt_licenses_c43b
wattroom_wt_pre_release_bug_review_d4dff5_f81b
wattroom_wt_soundboard_issue_check_bc080a_d36f

#2106 stops new ones appearing; these predate it.

[janlauber]

This is worse than "a stray container breaks every checkout", and I have now watched it happen.

The Postgres server is not a shared resource with a life of its own. It is one worktree's compose project, and its lifetime is that worktree's. Observed over about an hour today:

	container	wattroom_*wt_* databases
before	blissful-tesla-682eac-postgres-1	10 stranded + the live ones
after	strava-post-ride-image-6dc876-postgres-1	4

blissful-tesla's worktree was torn down, and every database inside it went with it — not just its own. The ten stranded pairs #2105 reported are gone, which is convenient, but they went the same way a live worktree's would have.

What survived is telling: wattroom is present because something recreated it on demand, and wattroom_test is simply gone.

Why this reframes the issue

AGENTS.md says: "Still shared, and not fixable by hashing: one Postgres server (separate databases inside it)." That reads as a stable thing the checkouts agree to share. It is not — it is owned by whichever worktree ran make infra first, and any agent tearing down its own worktree takes everyone's databases with it, including the main tree's.

Per-checkout database names (#552, #2096) solved collisions between checkouts. They did nothing about the server underneath having a single, arbitrary owner.

The cost is bounded — dev and test databases are created on demand and the server migrates at boot, so this is lost time rather than lost work. But an agent mid-task loses its database with no warning and no obvious cause, and the symptom (make refusing, or a suddenly-empty schema) points anywhere but at a neighbour's docker compose down.

What it means for the fix

Bringing the worktree's compose project down before removing it — the shape I suggested above — is now clearly wrong on its own, because that project may be the one everybody is using. The server wants an owner that is not a worktree: a named project that no checkout's teardown can reach (docker compose -p wattroom-shared), started by make infra wherever it runs, so git worktree remove and make worktree-gc cannot take it out from under anyone.

That is a change to how make infra works and to AGENTS.md's description of what is shared, so it wants deciding rather than patching.

[svengerber]

Taking this on `fix/shared-infra-project`, following the reframing above: `make infra` gets a fixed compose project (`-p wattroom`, so the main tree's existing project, container name and `wattroom_pgdata` volume are exactly what everyone converges on) instead of one derived from whichever directory ran it. dev-env.sh resolves that project by label first, so two strays no longer make every checkout refuse, and worktree-gc reports running postgres containers outside it with the docker rm -f — reported, never removed, since another clone looks identical from here. AGENTS.md's "one Postgres server" paragraph gets corrected to say who owns it.