Correction: the jax-compile-stall is not a compile stall

[Jammy2211]

Follow-up to #278. The two 1800s re-timing runs that were still in flight at close-out finished, and the faulthandler stack they captured contradicts the premise the whole epic was filed under.

The evidence

Both runs dumped at 1440s, exactly as PyAutoFit#1518 intended. Two different repos, two different scripts, the same stack:

Thread 0x00007fbf1f0e4b80 (most recent call first):
  File ".../jax/_src/api.py", line 2764 in try_to_block
  File ".../jax/_src/api.py", line 2781 in block_until_ready
  File ".../autofit/non_linear/jax_compile.py", line 264 in wrapper
  File ".../scripts/imaging/jax_likelihood/mge_group.py", line 175 in <module>

jax_compile.py:264 is the jax.block_until_ready(result) call — the second half of the wrapped first call. The process is not tracing, lowering or compiling. func(*args, **kwargs) returned. What never returns is the wait for the result to materialize.

What this changes

• Every marker, issue and prompt in this epic calls it an "intermittent XLA compile stall". That name is wrong, and has been since the first quarantine on 2026-08-01 — it was a guess made before any evidence existed. Corrected in the record, epics.md, the campaign ledger, and the follow-up smoke-timing task, so the speed-up work doesn't restart from the wrong question.
• A defect in log_on_first_compile, worth fixing before anyone reads another of these logs: the heartbeat prints JAX jit still compiling ... 1770s elapsed while the process sits in block_until_ready. The wrapper can't tell which half it's in and says "compiling" regardless. That wording actively reinforced the wrong diagnosis for the full 1770 seconds.
• Both entries are AMBIGUOUS even at 1800s — 2/2 capped on both legs. With the 300s round that's 20 consecutive cap hits and zero completions for each, while multi_dataset/mge.py's own marker records it finishing in 32s standalone.

Where a resumption should start

Not "why is XLA slow to compile" but "why does block_until_ready never return". The record lists three candidates: a device-transfer / async-dispatch hang (try_to_block is exactly where a never-arriving buffer parks); the compilation cache, still live but for a different reason (a cache read satisfying the compile instantly and leaving execution to hang fits what's seen); and the vmap(jit) ordering result reinterpreted — the ordering changes the shape of the executed computation, which is a more plausible route to an execution hang than to a compile one.

Note

The epic stays closed as partial — this sharpens the diagnosis, it does not root-cause it, and nothing is un-quarantined. Branch restarted from main after #278 merged, per the merged-PR rule.

lifecycle.py check: OK. Index and dashboard regenerated.

---

Generated by Claude Code