Skip Reactant Core tests when Reactant_jll is unavailable (fixes x86 CI)

[ChrisRackauckas-Claude]

Summary

Master Core CI on ubuntu-latest x86 fails with UndefVarError: libReactantExtra not defined in Reactant_jll because Reactant_jll ships no 32-bit artifact (run https://github.com/SciML/NeuralOperators.jl/actions/runs/37251088419). This PR defines const REACTANT_AVAILABLE = Reactant_jll.is_available() once in the shared test setup (via using Reactant: Reactant_jll), gates the eight Reactant-dependent sites with if REACTANT_AVAILABLE, and asserts REACTANT_AVAILABLE || Sys.WORD_SIZE == 32 so a missing artifact on a 64-bit lane fails loudly instead of silently dropping jit/gradient coverage. CPU-only size/forward checks still run on 32-bit.

Verification

Confirmed API in the resolved Reactant stack:

# x64: julia +1 --project=test
is_available() = true

# x86: julia +1~x86 --project=test
is_available() = false
isdefined(Reactant_jll, :libReactantExtra) = false

Core group on x64 after the review fix (GROUP=Core julia +1 --project=test -e 'include("test/runtests.jl")'): unchanged from the prior Reactant-gated counts except FNO +1 for the availability assertion:

Fourier Neural Operator | 15   # was 14; +1 = @test REACTANT_AVAILABLE || Sys.WORD_SIZE == 32
DeepONet                | 10
NOMAD                   | 10
SpectralConv            | 12
SpectralKernel          | 14
Transform Interface     | 15
Precompile workload     |  3

x86 Core (GROUP=Core julia +1~x86 --project=test -e 'include("test/runtests.jl")') exits 0; the new assertion passes; no libReactantExtra errors:

Fourier Neural Operator | 6   # 5 CPU checks + availability assertion
DeepONet                | 2
NOMAD                   | 2
SpectralConv            | 3
SpectralKernel          | 5
Transform Interface     | 15
Precompile workload     | 3

Runic --inplace and typos clean on the changed .jl files.

Not verified

• Full GitHub Actions Core matrix (Windows/macOS/pre); only local x64 + local +1~x86.
• GPU group / self-hosted CUDA.
• Round-1 finding 2 (direct Reactant_jll test dep instead of using Reactant: Reactant_jll) not yet addressed.

Please ignore this draft until reviewed by @ChrisRackauckas.

Risk assessment

• Risk: Low — tests-only gate; no production code changes. Availability assertion prevents silent Reactant dropout on 64-bit.
• Blast radius: Core / GPUCore test suites that include Reactant paths; platforms where REACTANT_AVAILABLE is false skip those paths only (and must be 32-bit or the assertion fails).
• Evidence: Local x64 counts = prior gated suite + 1 assertion; local x86 Core green with assertion passing; is_available() true on x64 / false on i686.
• Independent review: round 1 CHANGES (Claude Code Opus 5.5); blocking finding 1 addressed in 72a3bab.
• Merge: needs review

Harness: Cursor Agent CLI 2026.10.01-14929f9; model: auto; transcript: /home/crackauc/sandbox/goals/qa-hygiene/jobs/npo-reactant/log.txt

Independent review: Devin Fusion (fusion-claude-opus-5-5-high-sidekick-swe-2-medium) rated it low, verdict MERGE: #175 (comment)

[ChrisRackauckas]

🤖 Automated comment from an AI agent running as @ChrisRackauckas — not written or reviewed by Chris.

Independent review (Devin CLI 3000.11.3, model fusion-claude-opus-5-5-high-sidekick-swe-2-medium): MERGE, risk low.

Full review

VERDICT: MERGE
RISK: low

PR: #175. It changes tests only. Each Reactant @jit and gradient site is wrapped in if REACTANT_AVAILABLE, where REACTANT_AVAILABLE = Reactant_jll.is_available(). FNO also gets one assertion: @test REACTANT_AVAILABLE || Sys.WORD_SIZE == 32. The PR links no issue. The x86 lane comes from #167.

Blocking findings

None.

Non-blocking findings

1. The PR uses a binding Reactant does not make public (test/shared_testsetup.jl:2, using Reactant: Reactant_jll). Confirmed by running: Base.ispublic(Reactant, :Reactant_jll) = false and Base.isexported(...) = false (Reactant v0.2.291, Reactant_jll v0.0.416). The import form gets around that. The PR body itself lists this as unaddressed round-1 finding 2. The failure mode is loud: an UndefVarError at setup, not a silent skip. Cleaner fix: add Reactant_jll to test/Project.toml [deps]/[compat] and write using Reactant_jll. is_available() is the standard JLLWrappers-generated function. It returns false when no host-platform artifact exists (JLLWrappers/src/toplevel_generators.jl:199-204), so it is the right predicate.
2. Sibling-PR conflict (suspected from reading). feat: implement ConvolutionalNeuralOperator (CNO) (closes #122) #134 (CNO, open) adds test/models/cno_tests.jl with an ungated reactant_device(; force = true) and @jit. Whichever of the two merges second will turn the x86 lane red again unless CNO adopts the REACTANT_AVAILABLE gate. Gating each call site means every future Reactant test must remember to do it. A shared helper would be harder to forget, e.g. reactant_testset(f) or a single xdev = REACTANT_AVAILABLE ? reactant_device(; force = true) : nothing plus a guard. That is optional.
3. The assertion lives only in fno_tests.jl. That is enough today because every Core/GPUCore run includes FNO first. If FNO is ever moved or split, the 64-bit guard goes with it. Putting it in shared_testsetup.jl, or in a small testset in runtests.jl, would decouple it. Optional.
4. Style. if REACTANT_AVAILABLE; xdev = ...; end leaves xdev undefined on 32-bit. It is correct because every later use is under the same gate. A ternary would be tidier. No functional issue.
5. Unrelated noise (confirmed from the CI log). The x86 job prints repeated CpuId ... cpuid leaf 0x00000004 precompile LoadErrors from a transitive dependency. The tests still run and pass. This is not caused by the PR.

On the review checklist: no tolerances changed (the FNO 1f-1 tolerance and its comment pre-date the PR and only moved under the gate). No expected values changed, and no @test_skip/@test_broken was added. The one comment added is present-tense and gives the reason. There are no new dependencies and no src changes.

What I ran

• gh pr view 175, git diff origin/main...HEAD, gh pr checks 175. All 18 checks pass, including Core (julia 1, ubuntu-latest, x86), Windows, macOS, and GPU.
• Confirmed the bug on main. Downloaded the main run https://github.com/SciML/NeuralOperators.jl/actions/runs/37251088419, job 111578747107 (x86). Result: UndefVarError: libReactantExtra not defined in Reactant_jll, FNO 5 pass / 3 error.
• Compared test counts, main vs PR, in CI logs.
  • Main x64 ubuntu (job 111578747120): FNO 14, DeepONet 10, NOMAD 10, SpectralConv 12, SpectralKernel 14, Transform 15, Precompile 3.
  • PR x64 ubuntu (job 113579379733) and Windows (job 113579379564): FNO 15, all others identical. The only addition is the assertion, so no Reactant coverage is lost on 64-bit lanes.
  • PR x86 (job 113579379502): FNO 6, DeepONet 2, NOMAD 2, SpectralConv 3, SpectralKernel 5, Transform 15, Precompile 3. No libReactantExtra errors.
  • These match the PR body exactly.
• Ran locally (macOS aarch64, Julia 1.12.7, in a scratch copy): GROUP=Core julia +1.12 --project=test -e 'include("test/runtests.jl")'. All pass with the same counts as CI x64: FNO 15, DeepONet 10, NOMAD 10, SpectralConv 12, SpectralKernel 14, Transform 15, Precompile 3.
• Probe: Reactant_jll.is_available() = true, isdefined(Reactant_jll, :libReactantExtra) = true, plus the ispublic/isexported results quoted in finding 1.
• Mutation probe: forced const REACTANT_AVAILABLE = false on 64-bit. The FNO assertion fails at fno_tests.jl:6 (5 pass, 1 fail) and Julia exits nonzero. So a missing artifact on a 64-bit lane fails loudly rather than silently dropping jit/gradient coverage, as the PR claims.
• git status in the review checkout afterwards: clean.

What I did not verify

• I did not run the x86 lane locally (no i686 Julia on macOS arm64). For that lane I rely on the CI job log above, which I read.
• I did not run the GPU group locally. Its CI check passes.
• pre lanes: CI skips these ("Julia 1.13.1 is not a release candidate"), so they give no evidence either way.
• I did not check Runic or typos locally. Both CI checks pass.

---

🤖 Posted by an AI agent — harness: Devin CLI 3000.11.3 (review), Claude Code 2.1.285 (posting) · model: fusion-claude-opus-5-5-high-sidekick-swe-2-medium
Conversation: local Claude session 3c311569-dda6-4687-bc9f-65febb212c33 (fleet master)