[ChrisRackauckas]

🚧 UNREVIEWED — awaiting review by @ChrisRackauckas. Filed by an AI agent running as @ChrisRackauckas; Chris has not seen this.
Harness: Devin CLI 3000.11.92 (diagnosis and fix), Claude Code 2.1.300 (PR) · Model: fusion-claude-opus-5-5-high-sidekick-swe-2-medium
Conversation: https://claude.ai/code/session_01VZjwf7Ux9YtTzwHGHMqnsq (fleet master)

This fixes a failure on the default branch's CI. The diagnosis and the evidence below come from the investigating agent's report; "confirmed by running" and "read in logs" are kept apart there.

Four distinct failures across the three runs. Two come from Symbolics releases (fixed on the local branch), one is an MTK/SteadyStateDiffEq design issue already covered by a draft PR stack, and one is a non-deterministic segfault.

• 51a53cbce Fix variable_parsing test for Symbolics 7.43 scalar default check
• bc1ad01ab Update latexify 50.tex for Symbolics 7.45 align output (also raises Symbolics compat floor to 7.45)
• f497f76e5 Raise Latexify compat floor to 0.16.6

Files: lib/ModelingToolkitBase/test/variable_parsing.jl, lib/ModelingToolkitBase/test/latexify/50.tex, lib/ModelingToolkitBase/Project.toml.

---

1. Sublibrary CI, InterfaceI (Julia lts and 1): Parsing Test error

Error (read in logs):

Parsing Test: Error During Test
  LoadError: ArgumentError: Variable x must have default of matching size. Got [1, 2] with size (2,).
    [1] setdefaultval(...) @ Symbolics ~/.julia/packages/Symbolics/N7w3y/src/variable.jl:53
    [2] top-level scope @ lib/ModelingToolkitBase/test/variable_parsing.jl:66
Some tests did not pass: 1772 passed, 0 failed, 1 errored, 5 broken.

• Run: https://github.com/SciML/ModelingToolkit.jl/actions/runs/38488998911
• Jobs: https://github.com/SciML/ModelingToolkit.jl/actions/runs/38488998911/job/115657054545 (lts), https://github.com/SciML/ModelingToolkit.jl/actions/runs/38488998911/job/115657054737 (Julia 1)

Cause: upstream release, Symbolics v7.43.0 (JuliaSymbolics/Symbolics.jl PR 2041, "Reject scalar @variables with array-shaped defaults"). The test declares a scalar x with default [1, 2], which Symbolics now rejects on purpose. That makes the old test expectation wrong: a scalar variable with a vector default is invalid input.

• When it started (read in logs): the last green MTKBase InterfaceI run on master was 3c6ee5e (run 37353139498, job 111909716551, Symbolics 7.42.0). The first red one was d4443f3 (run 37477127037, job 112315954155, Symbolics 7.43.0). Between those two runs the only MTK commit was a collect_vars! change. The manifest diff shows Symbolics 7.42.0 -> 7.43.0, plus unrelated LazyArrays, Atomix and UnsafeAtomics bumps. Symbolics 7.43.0 was published 2026-10-05T21:45Z, between the two runs.
• Confirmed by running: on master with julia +release 1.13.2 and Symbolics 7.45.0, variable_parsing.jl fails with the same ArgumentError.

Existing PR: #5247 by ChrisRackauckas-Claude, draft. It has the correct test change, but its CI is red: the latexify failure (section 2) is still present on it, and its last run had jobs timing out or cancelled. On its own it does not turn master green.

Fix (commit 51a53cbce, the same diff as PR 5247): both declarations become x[1:2] = [1, 2] with the same connect/unit metadata, and the assertions use the public ModelingToolkitBase.getdefault(x) == [1, 2]. The metadata coverage stays the same.

• Before: LoadError: ArgumentError: Variable x must have default of matching size. Got [1, 2] with size (2,)., 0 passed, 1 errored.
• After: 48/48 pass (julia +release, Symbolics 7.45.0).
• At the new floor: 48/48 pass (julia +lts 1.10.12, Symbolics pinned to 7.45.0).

2. Sublibrary CI, RegressionI (Julia lts and 1): Latexify recipes Test reference mismatch

Error (read in logs):

Info: Reference Test for "50.tex" failed:
- \begin{equation} \left[ \begin{array}{c} \mathrm{connect}\left( P_{+}output, C_{+}input \right) \\ ...
+ \begin{align}
+ 0 &= \mathrm{connect}\left( P_{+}output, C_{+}input \right) \\
...  \frac{\mathrm{d} \cdot ...  ->  \frac{\mathrm{d}\mathtt{P.x}...,  \cdot -> ~
LoadError: To update the reference images ... at lib/ModelingToolkitBase/test/latexify.jl:68

• Jobs: https://github.com/SciML/ModelingToolkit.jl/actions/runs/38488998911/job/115657054604 (Julia 1), https://github.com/SciML/ModelingToolkit.jl/actions/runs/38488998911/job/115657054748 (lts)

Cause: upstream releases. Symbolics v7.43.0 (JuliaSymbolics/Symbolics.jl PR 2042) stops leaking mult_symbol after \mathrm{d}. Symbolics v7.45.0 (JuliaSymbolics/Symbolics.jl PR 2079) renders every Vector{Equation} in align and shows connect/AnalysisPoint rows as 0 &= .... Both are deliberate rendering changes. The new output (aligned &=, no doubled \mathrm{\mathtt{..}}) is the intended form, so the old reference is stale.

• It started at the same master transition as section 1 (read in logs: job 111909716997 green with Symbolics 7.42.0, job 112315953398 red with Symbolics 7.43.0).
• Confirmed by running: master fails on 50.tex.
• Downgrade interaction (read in logs, then confirmed by running): the Downgrade job resolves Symbolics 7.41.1 and Latexify 0.16.0, the floors. With those versions the old 50.tex passes, which is why downgrade RegressionI is green on master. Updating the reference therefore requires raising both floors. The PR 5250 and PR 5263 runs show downgrade RegressionI failing for exactly this reason.
  • Confirmed by running (observed in the run; the failing log was overwritten by the passing rerun, so only the passing log is kept): with julia +lts, Symbolics 7.45.0 and Latexify 0.16.0, the new 50.tex fails (=& instead of &=, \cdot instead of ~). Latexify versions below 0.16.6 ignore the mult_symbol kwarg that Symbolics' Latexify extension passes (korsbo/Latexify.jl PR 325, first released in 0.16.6). With Latexify 0.16.6 and Symbolics 7.45.0 on lts it passes.

Existing PRs: #5250 (Symbolics PR 2042 refs) and #5263 (stacked on 5250; Symbolics PR 2079 refs), both by ChrisRackauckas-Claude, draft, CI red. The net 50.tex in PR 5263 is correct and is byte-identical to the CI "actual" output. Neither PR bumps compat, so with them the Downgrade RegressionI job would turn red. They do not fix master on their own.

Fix (commits bc1ad01ab and f497f76e5): 50.tex is set to the net content of PR 5263. In lib/ModelingToolkitBase/Project.toml, Symbolics = "7.41.1" becomes "7.45" and Latexify = "0.16" becomes "0.16.6". Symbolics 7.45 needs SymbolicUtils >= 4.46.4, and the Downgrade resolver already picks 4.46.4 today, so the resolve still works.

• Before: Reference Test for "50.tex" failed, 1 errored.
• After: pass (julia +release, Symbolics 7.45.0, Latexify 0.16.12).
• At the new floors: pass (julia +lts, Symbolics 7.45.0 + Latexify 0.16.6 pinned).

Full-group verification of the branch (confirmed by running, julia +release, Pkg.test() in lib/ModelingToolkitBase)

• GROUP=InterfaceI: InterfaceI | 1803 Pass, 5 Broken, 1808 Total, 10m29.8s, "tests passed". The 5 broken tests were already marked broken; none were added.
• GROUP=RegressionI: Latexify recipes Test | 5 5, "tests passed".
• Runic --check on variable_parsing.jl: clean. typos on the changed files: clean.
• Not run locally: the full Downgrade job (julia-downgrade-compat resolve), QA, other groups, and julia pre. The floors were checked by pinning, not by the downgrade action.
• Auto-created latexify/10.tex–40.tex are not tracked in git, as on master. ReferenceTests creates them on each run, and they were deleted, not committed.

3. IntegrationTest, SciMLBase.jl/SymbolicIndexingInterface/1/: BoundsError on a steady-state solution

Error (read in logs):

Non-timeseries indexing SciMLBase.NonlinearSolution | 26 pass, 2 error
State indexing: Error During Test at downstream/test/downstream/comprehensive_indexing.jl:127
  BoundsError: attempt to access 1-element Vector{Float64} at index [[1, 2]]
Observed: Error During Test at .../comprehensive_indexing.jl:164  (same BoundsError)

• Run: https://github.com/SciML/ModelingToolkit.jl/actions/runs/38488998119 , job https://github.com/SciML/ModelingToolkit.jl/actions/runs/38488998119/job/115643833609

Cause: a bug in this repo's SteadyStateProblem SCC lowering combined with SteadyStateDiffEq (read in logs plus code reading; not reproduced locally). The failing object is the second NonlinearSolution in the list, sssol = solve(ssprob, DynamicSS(Tsit5())) on the 2-state osys. Its state_values has length 1. That matches SciML/SteadyStateDiffEq.jl#171: since SteadyStateDiffEq 2.18 (PR 169) together with MTK 11.45 (MTK PRs 5155/5163, the lowered_problem / steady_state_sccprob path in src/problems/sccnonlinearproblem.jl), solve(::SteadyStateProblem) returns the solution of the mtkcompiled lowered problem. That solution has reduced, reordered unknowns, not the original problem's layout.

• When it started (read in logs): the SII job has been red on master since 0e0bd07 (2026-09-17; last green was 52a3cf5, job 105108607531). The symptom changed over time. First it was TypeError: expected ParameterBindingsGraph, got Nothing in _sccprob, then FieldError: SCCNonlinearProblem has no field u0 (through 2026-10-10, both errors from init(ssprob, DynamicSS)). SciMLBase SciML/SciMLBase.jl@c8ea9caea (PR 1635, 2026-10-10) dropped that init, and since then the job gets further and fails with the BoundsError (first seen in run 38100651261, job 114355712788). It is not a flake: it fails on every master run.
• Chris has chosen a design (2026-10-14): replace the post-solve SCC reversal with a separate SCCSteadyStateProblem. A local patch would conflict with that, so I made no change on the branch.

Existing PRs (a three-PR draft stack; CI cannot pass until the upstream PRs are released):

• Add SCCSteadyStateProblem, the SCC-split form of a steady-state problem SciMLBase.jl#1642 by ChrisRackauckas, draft: adds SCCSteadyStateProblem.
• Construct SCCSteadyStateProblem from a System; drop the deferred SCC lowering #5276 by ChrisRackauckas, draft: constructs it from a System and drops the deferred SCC lowering. Its body lists open design questions.
• Solve SCCSteadyStateProblem; stop routing SteadyStateProblem through a lowering SteadyStateDiffEq.jl#178 by ChrisRackauckas, draft: solves it and stops routing SteadyStateProblem through the lowering.
• Superseded alternatives: SteadyStateDiffEq PRs 175 and 177 (ChrisRackauckas-Claude, drafts).
  I have not verified that the stack fixes this particular SII test. The stack's description says plain SteadyStateProblem solves no longer go through the lowering, which should restore sol.u to the problem's order.

4. Downgrade Sublibraries, downgrade-mtkbase (InterfaceI): segfault in Sundials KINSOL

Error (read in logs):

[4154] signal (11.2): Segmentation fault
in expression starting at lib/ModelingToolkitBase/test/odesystem.jl:351   (solve(prob, IDA()) on a DAEProblem)
kinLsDenseDQJac / kinLsSetup / KINSol in libsundials_kinsol.so
#___kinsol @ Sundials/src/simple.jl:17 <- initialize_dae! (Sundials/src/common_interface/initialize.jl:97)
Package ModelingToolkitBase errored during testing (received signal: 11)

• Run: https://github.com/SciML/ModelingToolkit.jl/actions/runs/38488998594 , job https://github.com/SciML/ModelingToolkit.jl/actions/runs/38488998594/job/115743698227 (Julia 1.10.12, Sundials 6.5.0 floor, Sundials_jll 7.5.0+0)

Cause: flaky (non-deterministic native segfault), read in logs, not reproduced locally.

• PR [blocked on Symbolics release] Update latexify references for Symbolics#2042 #5250 ran the same downgrade-mtkbase (InterfaceI) job on 2026-10-14 15:50. That run merged into the same master and touched only 50.tex. It resolved a byte-identical package set (284 entries, diff empty against the failing job), and it passed: https://github.com/SciML/ModelingToolkit.jl/actions/runs/38592893007/job/115952340831 .
• The previous master run of this job (37d63bc, job 114355763689) also passed. Its manifest differs only by unrelated patch bumps (MTKBase 1.77.3 -> 1.77.4, SciMLOperators, Integrals, ...).
• Before this run, the Downgrade workflow was red only because of downgrade-mtkbase (Optimization). That job passes in the 2026-10-14 run, after aea9c2e.
• A memory-safety bug in Sundials 6.5.0's KINSOL wrapper (for example a residual closure being GC'd during the DQ Jacobian) is possible. That is a guess and is not verified. If the segfault comes back, the next step is to loop odesystem.jl's prob4/prob5 IDA solves with Sundials 6.5.0 on Julia 1.10.
• No existing PR. Action: re-run the job.

---

Links

• Failed master runs: https://github.com/SciML/ModelingToolkit.jl/actions/runs/38488998594 (Downgrade Sublibraries), https://github.com/SciML/ModelingToolkit.jl/actions/runs/38488998119 (IntegrationTest), https://github.com/SciML/ModelingToolkit.jl/actions/runs/38488998911 (Sublibrary CI)
• fix: array variable defaults in variable_parsing for Symbolics#2041 #5247: variable_parsing fix (same change as commit 51a53cb)
• [blocked on Symbolics release] Update latexify references for Symbolics#2042 #5250: latexify refs for Symbolics PR 2042
• [blocked on Symbolics#2079 and #5250] Update latexify references for Symbolics#2079 #5263: latexify refs for Symbolics PR 2079 (same 50.tex as commit bc1ad01, no compat floors)
• Construct SCCSteadyStateProblem from a System; drop the deferred SCC lowering #5276: MTK part of the SCCSteadyStateProblem stack
• Add SCCSteadyStateProblem, the SCC-split form of a steady-state problem SciMLBase.jl#1642: SciMLBase part of the stack
• Solve SCCSteadyStateProblem; stop routing SteadyStateProblem through a lowering SteadyStateDiffEq.jl#178: SteadyStateDiffEq part of the stack
• solve(::SteadyStateProblem) returns the lowered problem's solution: sol.u reordered/empty, sol.prob.f.sys time-independent SteadyStateDiffEq.jl#171: issue describing the lowered-solution layout bug
• https://github.com/JuliaSymbolics/Symbolics.jl/releases/tag/v7.43.0: contains PRs 2041 and 2042
• https://github.com/JuliaSymbolics/Symbolics.jl/releases/tag/v7.45.0: contains PR 2079
• https://github.com/SciML/ModelingToolkit.jl/actions/runs/38592893007/job/115952340831: passing downgrade InterfaceI on the identical manifest (flake evidence)

Nothing was pushed, commented, or opened. gh was used read-only.

---

🤖 Posted by an AI agent — harness: Devin CLI 3000.11.92 (fix), Claude Code 2.1.300 (PR) · model: fusion-claude-opus-5-5-high-sidekick-swe-2-medium / claude-opus-5-5
Conversation: https://claude.ai/code/session_01VZjwf7Ux9YtTzwHGHMqnsq (fleet master)

🤖 Generated with Claude Code

Independent review (added by the fleet master)

Risk assessment

• Risk: low
• Blast radius: ModelingToolkitBase test expectations and supported dependency resolutions; the root ModelingToolkit downgrade test environment also consumes the in-tree sublibrary. No runtime implementation or public API changes.
• Evidence: Reviewed latest head 8fbc442, including its root Latexify floor update. Read the failed root Downgrade log for the preceding head, confirming why the root floor is necessary. CI restarted for the new head (latest snapshot: 14 successful checks, 59 in progress, eight queued, no failures); root and sublibrary Downgrade and the targeted sublibrary tests remain pending/running. Targeted tests were not independently run locally.
• Independent review: codex gpt-6.1-sol rated it low, medium confidence: upstream fixes justify the exact expectations and both Latexify floors now agree; the latest downgrade rerun is still unverified. Risk was rated low before reading the body, temporarily medium upon observing the resolver failure, and low after reviewing the corrective commit.
• Merge: auto-merge candidate — focused test/reference and compat maintenance, conditional on successful required CI, especially root and sublibrary Downgrade.

---

🤖 Section added by an AI agent — harness: Claude Code 2.1.300 · model: claude-opus-5-5 (review by codex-cli, gpt-6.1-sol)
Conversation: https://claude.ai/code/session_01VZjwf7Ux9YtTzwHGHMqnsq