fix(tests): use spawn instead of fork for lock-test subprocesses

[igorls]

Summary

Recent CI runs have been hanging on Linux 3.13 and macOS while Linux 3.9 / 3.11 and Windows finish normally. Same hang signature on every PR (#1396, #1430): pytest step starts, jobs run for 33+ minutes with no progress, get cancelled.

The cause is in two test files that explicitly request the fork start method for multiprocessing:

# tests/test_palace_locks.py and tests/test_chroma_collection_lock.py
start_method = "spawn" if os.name == "nt" else "fork"
return multiprocessing.get_context(start_method)

By the time these tests run, the pytest parent is multi-threaded — chromadb and onnxruntime both spawn background threads on import. When fork snapshots that state into a child without the threads themselves, any lock held by another thread at fork time stays locked in the child forever. Python 3.13 explicitly warns about this (we saw the DeprecationWarning 10 times in a local 3.13 run), and the timing window where Python's own internal threads hold locks widened in 3.13 enough to make the deadlock reproducible.

macOS hits a parallel issue: Apple's CoreFoundation forbids fork-without-exec. Anything ONNX/Obj-C-bridge-touching that loaded in the parent will silently hang the moment the forked child touches the same library — independent of Python version.

Change

Switch both _get_mp_context() helpers to use multiprocessing.get_context("spawn") unconditionally. Lock-file semantics are unchanged: spawn inherits os.environ (including monkeypatched HOME), which is all these tests need from the parent. Trade-off is per-Process import overhead (~0.5s on Linux), bounded by the small number of subprocesses these tests fork (10 across both files).

Test plan

• uv run --python 3.13 pytest tests/test_chroma_collection_lock.py tests/test_palace_locks.py -v → 14 passed in 6.58s
• ruff check and ruff format --check (CI-pinned ruff>=0.4.0,<0.5) → clean
• CI green on Linux 3.9/3.11/3.13, Windows, macOS, lint
• Linux 3.13 + macOS no longer hang

Notes

• The test docstrings claimed fork was preferred for speed; that reasoning is now obsolete (or rather, was always at risk). The new docstrings explain why spawn is required.
• This is independent of chore(tests): wrap sqlite3 connections in contextlib.closing #1430 (sqlite cleanup). They can land in either order.

[gemini-code-assist]

Code Review

This pull request updates the multiprocessing start method to always use "spawn" in tests/test_chroma_collection_lock.py and tests/test_palace_locks.py. This change addresses potential deadlocks in multi-threaded environments under Python 3.13 and ensures compatibility with macOS, where fork-without-exec is restricted. I have no feedback to provide.

[Copilot]

Pull request overview

This PR addresses CI hangs caused by using the fork multiprocessing start method in lock-related tests after the pytest parent process has become multi-threaded (notably due to chromadb/onnxruntime imports). It standardizes these tests to use spawn across all platforms to avoid fork-related deadlocks and macOS fork restrictions.

Changes:

• Switch _get_mp_context() in two test modules to always return multiprocessing.get_context("spawn").
• Update docstrings to document why fork is unsafe in this test environment (Python 3.13 thread-at-fork issues, macOS CoreFoundation behavior).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
tests/test_palace_locks.py	Use spawn unconditionally for subprocess lock contention tests; expand rationale in docstring.
tests/test_chroma_collection_lock.py	Use spawn unconditionally for subprocess lock contention tests; expand rationale in docstring.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.