[e-lo]

Summary

test_write_duckdb_while_a_reader_holds_the_file (added in #251) failed intermittently under pytest -n auto on macOS. The child that reopens the DuckDB file exited with -11 and produced no stdout or stderr.

Cause. The failure had nothing to do with DuckDB locking or a shared instance. Every macOS crash report shows the same stack:

subprocess_fork_exec → fork → _pthread_atfork_child_handlers
  → PROJ SQLiteHandleCache::getHandle atfork lambda → lru cache clear
  → sqlite3Close → unixClose → verifyDbFile → sqlite3_log → os_log → SIGSEGV

The forked copy of the xdist worker crashes before exec. pyproj/PROJ is loaded by the geo tests that run on the same worker, and it registers an atfork-child handler that closes its cached SQLite handles. On macOS, that close path calls os_log, which is not safe to call after fork. subprocess.run with the default close_fds=True forks on macOS because the platform has no POSIX_SPAWN_CLOSEFROM.

Fix. Pass close_fds=False (the executable, sys.executable, is already an absolute path) so subprocess uses posix_spawn, which runs no atfork handlers. This is the same workaround the run_node fixture, the project-cards harness and the documented-CLI contract tests already use. The change is test-only.

Verification

Full suite, uv run --all-extras pytest packages plugins -n auto -q -m "", macOS, Python 3.13.3:

• Before: 3 of 8 runs failed on this test (-11, empty output). All 3 have a matching crash report with the stack above.
• After: 20 of 20 runs passed (4308 passed, 6 skipped each), with no new crash reports.
• Checked that the call now goes through os.posix_spawn (the default call went through fork). ruff check and ruff format --check are clean.

🤖 Generated with Claude Code