Downgrade Core hangs after ANTLR initialization since #146

[ChrisRackauckas-Claude]

Regression

The Downgrade (Core) workflow no longer completes on main. Dependency resolution and package build succeed, then the julia-runtest step reaches Core ANTLR tests and never advances past ANTLR parser initialized successfully until GitHub cancels it at the six-hour execution cap.

Affected runs

• 4c85f397 downgrade run: started 2026-07-28 15:47:44 UTC, cancelled by the execution cap at 21:47:10 UTC.
• 1c5ff39 downgrade run: started 2026-07-27 04:45:47 UTC, cancelled at 10:45:15 UTC.

Both complete julia-downgrade-compat and julia-buildpkg in under one minute. The last test output in the current run is:

Testing Running tests...
Test Summary: Julia Parser Tests | 75 / 75 | 1m50.3s
Info: ANTLR parser initialized successfully

No ANTLR test summary or Julia error is emitted before cancellation.

Clean controls and introducer

• 6bf0435 downgrade run was green in 12 minutes. Its ANTLR tests completed (138 / 138) shortly after the same initialization message.
• The exact range 6bf0435..1c5ff39 has one commit: Require strict SciMLTesting 2.4 QA #146, 1c5ff39 (Require strict SciMLTesting 2.4 QA). This is therefore the first bad source revision.
• Normal current-head Core CI on 4c85f397 passes on LTS, current, and prerelease Julia; the regression is specific to the downgraded dependency graph.

Reproduction

1. Check out 4c85f397 (or 1c5ff39).
2. Run the repository downgrade workflow's julia-actions/julia-downgrade-compat@v2 resolution for group Core.
3. Run the corresponding GROUP=Core test step.

The hosted manifest resolves the direct compatibility floors, then hangs in the ANTLR Core test after initialization.

The likely interaction surface introduced by #146 is its stricter direct dependency bounds and PythonCall import/API cleanup; this report intentionally does not claim a specific line without a stable local reproduction of the exact downgraded manifest.

Scope

This is unrelated to QA-only issue #139 (implicit-import cleanup).

[ChrisRackauckas-Claude]

Follow-up graph comparison: the last green downgrade (6bf0435) and the failing post-#146 downgrade (1c5ff39, later 4c85f397) selected the same key direct compatibility graph: ModelingToolkit 11.24.0, ModelingToolkitBase 1.34.0, and PythonCall 0.9.29.

The green run completed ANTLR 138/138 in 1m04 after the initialization message. The newer source reaches the same initialization under that same graph and then hangs until the six-hour cap. Therefore raising one of these minimum versions would only mask a source regression introduced by #146; it is not a supported floor correction. The next investigation should bisect the #146 source changes while holding this graph fixed.

[ChrisRackauckas-Claude]

Further exact-lock probe:

• Reconstructed the CI julia-downgrade-compat deps manifest from action source 2c401f8b47edbcafc2e1edbff8e71f33dce71822 at 1c5ff39; it resolves ModelingToolkit 11.24.0, ModelingToolkitBase 1.34.0, PythonCall 0.9.29, SciMLBase 3.1.0, SymbolicIndexingInterface 0.3.43, SymbolicUtils 4.23.1, and Symbolics 7.18.1.
• Direct PythonCall control at that exact floor shows the likely is_null hunk is not causal: ctx == pybuiltins.None and ctx == Py(nothing) both return true for null Py values and false for integer Py values.
• A parser probe with flushed markers reached only probe_start; after two minutes it remained importing Symbolics, before BaseModelica loaded. It was stopped rather than misclassifying compilation as an ANTLR result.

This rules out a speculative compat change and the obvious None restoration. No source patch is proposed without a reproducible parser-level control.