[avallete]

TL;DR

The per-user port registry (~/.supabase/ports.sqlite) now opens in WAL mode, so a peer committing reservations no longer locks other connections out of opening or reading it.

• Network.integration.test.ts › retains dedicated assignments across network reopen failed on Windows with database is locked while opening the registry. Under the rollback journal, a peer that commits back to back holds the lock nearly all the time, and a new connection's schema read keeps losing the race until the 2s busy timeout runs out. Parallel test files that scan for ports produce exactly that write pattern. In WAL mode readers never wait on a writer. Writers still serialize through BEGIN IMMEDIATE, as before. A new integration test opens and reads the registry while a peer holds its write lock: it fails on the old code with the same database is locked error and passes with this change.
• Tradeoff: WAL needs shared memory, so a home directory on a network filesystem is not supported for this file.

ref

spotted in: https://github.com/supabase/cli/actions/runs/40438309049/job/121972299083

---

Generated by Claude Code

[avallete]

/ai-review

---

Generated by Claude Code

[github-actions]

Superseded by a newer AI review

🤖 AI Review

Code inspection confirms all three findings: two distinct test weaknesses and a low-impact contention case when migrating an existing registry to WAL. No findings were duplicates. Tests were not run.

Findings

Severity	Location	Category	Sources	Claim
🟡 MINOR	packages/stack/src/namespace/PortReservations.integration.test.ts:18	test-reliability	claude	The test derives the registry path from homedir(), while the service resolves the OS account home independently. An overridden HOME can make the assertion inspect the wrong file and the peer lock a different database.
🟡 MINOR	packages/stack/src/namespace/PortReservations.ts:99	error-handling	claude	Migrating an existing rollback-journal registry to WAL can fail under peer locks that previously allowed opening and reading the registry, and that failure aborts registry initialization.
🟡 MINOR	packages/stack/src/namespace/PortReservations.integration.test.ts:18	test-coverage	codex	The regression test can pass after production WAL initialization is removed because it reuses a database whose WAL mode persists between runs.

Stats

Claude findings: 2 · Codex findings: 1 · 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.

[github-actions]

🤖 AI Review

Both independent reviews completed; Codex reported no findings. Confirmed Claude's test-path mismatch, a low-risk shared-registry contention concern, and an import-grouping nit. No production defect was identified in the WAL initialization change.

Findings

Severity	Location	Category	Sources	Claim
🟡 MINOR	packages/stack/src/namespace/PortReservations.integration.test.ts:18	test-coverage	claude	The test derives the registry path from homedir(), while the service resolves the OS account home independently of HOME. When those differ, the test can fail or lock a different database and pass without exercising contention.
🟡 MINOR	packages/stack/src/namespace/PortReservations.integration.test.ts:23	test-reliability	claude	The test holds a write transaction on the shared per-user registry while reopening the service. Concurrent integration workers can exhaust their two-second writer timeout if this interval becomes slow.
⚪ NIT	packages/stack/src/namespace/PortReservations.integration.test.ts:5	style	claude	The node:crypto and node:os imports are separated by the Effect imports.

Stats

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

---

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

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

[github-actions]

Flaky test check: ✅ no flaky tests

Commit af47560b4c31 · focused ×10 (5 executions each), 8003 tests · integration ×10, 5633 tests · unit ×10, 8351 tests · workflow run

_{Each execution is a separate Vitest process; Where lists failing runs, as run.iteration for suites executed more than once per run. The full data is in the flaky-check-report artifact.}