Nautilus 1-core fits deadlock under JAX: fork Pool(1) bypasses nautilus's serial-pool guard (release-integrate RED)

[Jammy2211]

RED reason (verbatim, pyauto-brain health assess, 2026-08-01)

✗ [validate] release validation FAILED (stage integrate)

Stage reports: guides/modeling/advanced/hierarchical.py TIMEOUT (1800s) in both
run 30672739606 (manual Stage 3, 2026-07-31 23:23 UTC)
and run 30686136529 (nightly, 2026-08-01 05:35 UTC).
The same script passed at 76.0s in the 2026-07-31 05:43 UTC run — a deterministic 2/2 regression from changes merged 2026-07-31 daytime.

Authorization

Human instruction, quoted verbatim from the live CLI session (2026-08-01 evening), which launched this release push:

"can you do a wake up and then do a release, fine if any blockers need sorting, a paper goes live on monday and i want the latest version to be out"

Recorded here as the authorization for this corrective PR against the RED reason above. (Given at session launch for "any blockers" rather than after the specific reason string was surfaced; noted for the calibration log.)

Root cause

e6279c5 (#1439, merged 2026-07-31) changed Nautilus.fit_multiprocessing from passing pool=self.number_of_cores (an int) to always constructing fork_context().Pool(self.number_of_cores) and passing the pool object — including when number_of_cores == 1.

nautilus itself treats an int specially (nautilus/sampler.py:286):

if pool[i] in [None, 1]:
    pool[i] = None          # fully serial, in-process

A real Pool(1) object bypasses that guard, so every likelihood evaluation is shipped to a single forked worker process. Under the release profile (JAX enabled), the autolens likelihood touches JAX (log_likelihood_penalty_from → jnp.array), and a forked child of a JAX-initialized parent deadlocks in XLA backend_compile_and_load — the classic fork-after-JAX-init hang.

py-spy evidence (local repro under the release env, PYAUTO_TEST_MODE=1 PYAUTO_DISABLE_JAX=0):

• main process: nautilus … evaluate_likelihood → pool.map → wait (blocked forever)
• forked worker: log_likelihood_penalty_from → jnp.array → … → backend_compile_and_load (stuck)

Why only hierarchical.py: it is the one release-set script that fits a FactorGraphModel(use_jax=False) with Nautilus — analysis._use_jax=True scripts route to fit_x1_cpu (pool=None) and JAX-vectorized likelihoods never touch the pool. expectation_propagation.py fits node-by-node through the EP optimiser, not this path.

Fix (this PR, narrow)

In fit_multiprocessing, construct the fork-context pool only when number_of_cores > 1; pass pool=None for a single core — restoring the pre-#1439 serial behaviour while keeping the fork pinning (the actual Python 3.14 forkserver fix) for genuine multi-core runs. One file + one test.

Tests / evidence

• Unit test: Nautilus at number_of_cores=1 builds no multiprocessing pool (fork context not entered).
• Existing test_fork_context.py suite still passes.
• Control-vs-patched under the release-profile env: hierarchical.py hangs on current main (control, reproduced locally) and completes patched.

Validation plan

Merge → dispatch Stage 2 rehearsal (PyAutoHands) + Stage 3 release-integrate (PyAutoHeart) → pyauto-brain release validate --ingest → Heart re-verdict → scheduled nightly performs the release on green under the standing grant (PyAutoBuild#127).

Not claimed by this PR

autolens_test multi_dataset/jax_likelihood/delaunay.py intermittent TIMEOUT (07-30✗? no — 07-31 ✗, 08-01 ✗, passed 23:23 run at 18.2s; occurs across different library SHAs) is a separate pre-existing compile-side flake and is not cleared by this fix.

[Jammy2211]

Control-vs-patched complete under the release-profile env (PYAUTO_TEST_MODE=1, JAX enabled, full datasets):

• Control (main, 81f88fe..67c4090): hierarchical.py hangs — py-spy: main process blocked in nautilus pool.map → wait, forked worker stuck in jnp.array → … → backend_compile_and_load (XLA compile deadlock in a forked child). Killed after no progress.
• Patched (75dccb9): completes, exit 0, ~2 min locally.

Unit evidence: test__single_core_builds_no_pool is red on main (fork context entered at 1 core) and green on the branch; test_autofit/non_linear/ 411 passed, 1 skipped.

PR: #1443.

[Jammy2211]

Closed out — 2026-08-04

This shipped on 2026-08-01 (#1443, merge commit `5bf32dab`) and the issue
auto-closed at merge, but the PyAutoMind task entry was never advanced. Closing
it out now, with the production-CI verification the original evidence was
waiting on:

• Release Integrate run 30901054267 (2026-08-04T10:32, success) —
  `scripts/graphical/hierarchical.py ... PASS (6.8s)`. That is the exact script
  that raised this RED at a 1800s TIMEOUT (originally 76s).
• `pyauto-heart readiness --json` now returns `red_reasons: []`; the
  "release validation FAILED (stage integrate)" reason is gone.
• Post-merge integrate failures do exist on 08-01/08-03/08-04, but none are this
  script — they are `verify_install_release` and the autolens
  `point_source` / `multi_galaxy` script legs.

Still open and explicitly not claimed by this fix: the intermittent
`delaunay.py` TIMEOUT, which is pre-existing and crosses SHA windows.

Completion record: `PyAutoMind/complete/2026/08/nautilus-1core-serial-pool.md`.