Re-enable downgrade (strict, allow_reresolve=false); intentionally RED pending upstream ForwardDiff/LogExpFunctions (deeper than the LinearSolve wall) — red until ForwardDiff 1.3.4 (#811) — natural failure, not disabled; auto-greens on upstream release.#307
Merged
ChrisRackauckas merged 5 commits intoJun 7, 2026
Conversation
The downgrade workflow was disabled (if: false, issue SciML#292) because the old [compat] floors could not resolve/pass against the co-evolving modern SciML stack. Re-enable it with allow-reresolve: true and raise the floors to the lowest consistent set that resolves and passes on Julia 1.10: - DiffEqBase: 6.155.4 -> 6.190.2 (BrownFullBasicInit migrated to DiffEqBase; matching OrdinaryDiffEqCore >=1.35 requires DiffEqBase >=6.190.2) - DifferentiationInterface: 0.6.1 -> 0.7.3 (drop 0.6; NonlinearSolve >=4.12 / OrdinaryDiffEqNonlinearSolve >=1.15 need DI >=0.7.3, which carry the BrownFullBasicInit dispatch on the DiffEqBase-defined type) - SciMLBase: 2.54 -> 2.146 (2.115 fails NonlinearSolve precompile at runtime with DiffEqBase 6.190.x) - RecursiveArrayTools: 3.27 -> 3.36 - StaticArraysCore: 1.4 -> 1.4.3 (NonlinearSolveFirstOrder needs >=1.4.3) - PrecompileTools: 1.2 -> 1.2.1 (PreallocationTools >=0.4.31 needs >=1.2.1) - DataInterpolations: "5, 6" -> "5, 6, 7, 8" (test-only; >=8.6.1 allows PrettyTables 3 needed by SymbolicIndexingInterface) Downgrade.yml: removed `if: false`, set allow-reresolve: true (julia 1.10 retained per LTS policy). Downgrade suite run locally at these floors: PASS (329 passed, 0 failed, GROUP=Core, Julia 1.10, allow_reresolve=true). Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com> Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The downgrade job was set to allow-reresolve: true, which masks a genuine lower-bound conflict. Under strict resolution (allow-reresolve: false) at GROUP=Core, pinning the direct deps to their compat floors locks RecursiveArrayTools at 3.36.0. Any LinearSolve >= 3.29 requires RecursiveArrayTools >= 3.37.0, so RecursiveArrayTools 3.36.0 caps LinearSolve at the <= 3.36 line, while the test target's OrdinaryDiffEqNonlinearSolve floor pulls in LinearSolve >= 3.46. The intersection is empty, so the test environment is unsatisfiable without re-resolving (which would relax the floors) or raising the RecursiveArrayTools floor (a real compat change). Rather than hide the conflict with allow-reresolve: true, set allow-reresolve to false and disable the job (if: false) with an explanatory comment, so the downgrade gate is honest about the current floors. Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com> Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The reusable downgrade.yml workflow now always uses allow_reresolve: false and no longer accepts an allow-reresolve input. Remove the now-invalid input so the caller keeps working once SciML/.github @v1 is retagged. Behavior is unchanged: downgrade tests still run strictly with allow_reresolve=false. Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com> Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
Author
|
Pushed a follow-up commit removing the now-invalid |
Re-investigated re-enabling the strict (allow-reresolve: false) downgrade
suite at GROUP=Core. Bumping the RecursiveArrayTools floor (3.36 -> 3.37)
clears the LinearSolve wall, and bumping DiffEqBase (-> 6.217) + SciMLBase
(-> 2.154) lets the project environment resolve against the modern
OrdinaryDiffEq stack. However the strict test sandbox then dead-ends on a
ForwardDiff <-> LogExpFunctions conflict that no compat floor can fix:
- The project env resolves LogExpFunctions to 1.0.1 (transitive via
DiffEqBase, which caps it at no version), so it is fixed at 1.0.1 in the
allow-reresolve: false test sandbox.
- The test extra ForwardDiff (required by the domain/manifold tests)
hard-requires LogExpFunctions = "0.3" at EVERY version (0.10.23 .. 1.x),
so it can never coexist with the fixed LogExpFunctions 1.0.1.
This same wall reproduces with the latest unpinned stack, confirming it is
structural and not a downgrade-floor problem. It is only resolvable via
allow-reresolve: true (which would silently downgrade LogExpFunctions and
defeat strict downgrade testing). Keeping the job disabled and updating the
explanatory comment to reflect the real, floor-unfixable blocker.
No Project.toml floors changed; strict downgrade suite verified locally as
floor-unfixable (cannot resolve at any raised-floor set without a forbidden
allow-reresolve: true).
Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ending upstream Remove the if:false gating so the Downgrade job RUNS strict (allow_reresolve=false). It is expected RED until the upstream fix: ForwardDiff/LogExpFunctions (deeper than the LinearSolve wall) — red until ForwardDiff 1.3.4 (#811). Natural failure, not disabled; auto-greens on upstream release. Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com> Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
ChrisRackauckas-Claude
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Per repo-owner policy change: do NOT disable downgrade with
if: false.This re-enables the strict downgrade job for DiffEqCallbacks.jl so it RUNS and fails NATURALLY (visible red) instead of being skipped.
What changed
if: falsegating from thetest(Downgrade) job in.github/workflows/Downgrade.ymlso it has NOif:key and runs on every PR/push.allow-reresolve, did NOT lower any compat floors. Still calls the centralSciML/.github/.github/workflows/downgrade.yml@v1withjulia-version: "1.10",group: "Core",skip: "Pkg,TOML".Why it is (intentionally) RED
Strict resolution (
allow_reresolve=false) currently cannot resolve here. The wall is ForwardDiff/LogExpFunctions — deeper than the earlier LinearSolve wall: the project env fixes LogExpFunctions at 1.0.1 (transitive via DiffEqBase) while the test-extra ForwardDiff hard-requiresLogExpFunctions = "0.3"at every version, so they cannot coexist under strict mode. This is independent of our floors and reproduces on the latest unpinned stack.The job will be RED — that is intentional. It will auto-green when the upstream fix releases: ForwardDiff/LogExpFunctions (deeper than the LinearSolve wall) — red until ForwardDiff 1.3.4 (#811).
Please ignore this PR until it has been reviewed by @ChrisRackauckas.