Repository navigation
A small worktree repro: shared SQLite can hide a missing test fixture #59765
ryanroundhouse
started this conversation in
Show and tell
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
If you run Codex in several worktrees, a clean checkout can still be testing against another task's data. Here is a small, Python standard-library reproduction you can inspect and run without a coding agent or a database server.
The setup deliberately leaves out B's fixture-seeding step. A and B are separate Git worktrees at the same commit, running the same Python file and deliberately configured to use the same database path. The check asks whether an expected row exists; it does not establish which task created that row.
Observed sequence
On Linux with Python 3.12.14, SQLite 3.53.1 and Git 2.52.0:
Both Git worktrees remain clean. The code and check stay unchanged throughout. The changing database contents explain the result. This is a deliberately weak fixture-presence check that exposes a missing setup step, not evidence that the application's behavior is correct.
Reproduce it
Requires Python 3.9+ with sqlite3 and Git on PATH. Only the versions above were tested. Save this as
repro.pyoutside any repository, review it, then runpython3 repro.py. It creates a new temporary repository, two linked worktrees and synthetic SQLite files, verifies all six subprocess outcomes, and removes only its generated temporary folder after normal execution or handled exceptions. Abrupt termination can leave that temporary folder behind. It does not install packages, contact the network, use credentials, run agents or change an existing repository. Git and Python themselves must be trusted.Complete standalone reproduction
What to put in a review handoff
Alongside the tested commit and actual test command, record which database or fixture namespace the test used, who initialized it, and whether the test still passes from its own fresh fixture. Keep connection strings, credentials and private paths out of public reports. If multiple tasks intentionally share mutable state, serialize them or use an explicitly reviewed isolation scheme. Do not reset a shared database or kill another task's process just to get a green run.
This sequence is deterministic, not concurrent. It does not test locking, port allocation, Postgres, a Codex session or a Zozo Run. A separate SQLite file prevents this demonstrated contamination; it does not isolate every service, credential or host resource. Git's worktree documentation describes multiple working trees and shared repository resources, not separate application databases.
Disclosure: I'm Ryan, founder of Zozo HQ. This example and post were prepared with AI assistance. Our Local guide explicitly says agents run as the local user; I am not claiming Zozo automatically isolates external databases. This is a standalone environment check for anyone reviewing worktree-based coding work.
Which shared resource most often makes your local test result hard to reproduce: fixture data, a server port, a cache, or something else?
All reactions