Summary
The Downgrade workflow is red on clean master with:
KeyError: key "LibMPDec_jll" not found
...
Registries.jl:224
This is not caused by #498 or by a recent ArrayInterface source change. The same current action and registry fail on the last ArrayInterface commit whose historical workflow was green.
Reproduction
With Julia 1.10 and current v2 of julia-downgrade-compat:
git clone https://github.com/JuliaArrays/ArrayInterface.jl
git clone --branch v2 https://github.com/julia-actions/julia-downgrade-compat
cd ArrayInterface.jl
julia --startup-file=no ../julia-downgrade-compat/downgrade.jl \
"Pkg,TOML" "." "alldeps" "1" ""
The command fails deterministically with the LibMPDec_jll KeyError. It also fails after checking ArrayInterface out at db587545, so bisecting ArrayInterface source would be misleading.
External-action bisect
I bisected julia-actions/julia-downgrade-compat with the command above:
ac05e57de99d5cb35a381755d2054b57e8385c3b is the first bad commit
Handle old-style test dependencies (extras and targets.test) (#49)
That action change is desirable: it adds ArrayInterface's [extras]/[targets].test dependencies to the minimum-version solve. It exposes an existing Resolver/registry edge case; reverting it would reduce downgrade coverage rather than fix the cause.
Root cause
General's Python_jll metadata currently has:
# Compat.toml
["3-3.10"]
LibMPDec_jll = "2"
# Deps.toml
["3.10-3"]
LibMPDec_jll = "7106de7a-f406-5ef1-84f7-3345f7341bd2"
Thus Python 3.8 versions have a LibMPDec_jll compat entry but no active dependency with that name. Julia's Pkg tolerates this: on Julia 1.10, a project constrained to Python_jll = "~3.8" resolves to Python_jll v3.8.8+3 without LibMPDec_jll.
Resolver's compatibility shim for Julia <= 1.13 instead assumes every compat name occurs in the active per-version dependency map:
compat_uuid_pairs(c, name2uuid) =
(name2uuid[n] => spec for (n, spec) in c)
The unchecked name2uuid["LibMPDec_jll"] lookup is the crash.
Proper fix tested locally
I implemented a focused Resolver patch that:
- filters name-keyed compat entries with
haskey(name2uuid, name);
- filters Julia 1.14's UUID-keyed representation against the active dependency UUIDs too;
- applies the same rule to strong and weak dependencies; and
- adds a regression test using
Python_jll 3.8/3.10 plus a synthetic UUID-keyed check.
Observed verification:
- Before the patch, the new Resolver integration test reproduced the exact
KeyError.
- After the patch,
bin/test/runtests.jl passed 11/11 on Julia 1.10.
- Resolver's full
Pkg.test() passed on Julia 1.10 and Julia 1.12.
- ArrayInterface's exact downgrade command completed with the patched Resolver.
- The subsequent workflow-equivalent
Pkg.build(verbose=true) completed.
- The exact
GROUP=Core, allow_reresolve=false Pkg.test invocation passed all downstream testsets (336 assertions).
No ArrayInterface test or downgrade dependency was skipped, weakened, or suppressed.
The proper follow-up is an upstream Resolver patch. This issue records the clean-master failure and fully tested fix while that upstream contribution is coordinated.
Summary
The
Downgradeworkflow is red on cleanmasterwith:This is not caused by #498 or by a recent ArrayInterface source change. The same current action and registry fail on the last ArrayInterface commit whose historical workflow was green.
d767284, run 30054476628, job 89363223986db587545Reproduction
With Julia 1.10 and current
v2ofjulia-downgrade-compat:The command fails deterministically with the
LibMPDec_jllKeyError. It also fails after checking ArrayInterface out atdb587545, so bisecting ArrayInterface source would be misleading.External-action bisect
I bisected
julia-actions/julia-downgrade-compatwith the command above:That action change is desirable: it adds ArrayInterface's
[extras]/[targets].testdependencies to the minimum-version solve. It exposes an existing Resolver/registry edge case; reverting it would reduce downgrade coverage rather than fix the cause.Root cause
General's
Python_jllmetadata currently has:Thus Python 3.8 versions have a
LibMPDec_jllcompat entry but no active dependency with that name. Julia's Pkg tolerates this: on Julia 1.10, a project constrained toPython_jll = "~3.8"resolves toPython_jll v3.8.8+3withoutLibMPDec_jll.Resolver's compatibility shim for Julia <= 1.13 instead assumes every compat name occurs in the active per-version dependency map:
The unchecked
name2uuid["LibMPDec_jll"]lookup is the crash.Proper fix tested locally
I implemented a focused Resolver patch that:
haskey(name2uuid, name);Python_jll3.8/3.10 plus a synthetic UUID-keyed check.Observed verification:
KeyError.bin/test/runtests.jlpassed 11/11 on Julia 1.10.Pkg.test()passed on Julia 1.10 and Julia 1.12.Pkg.build(verbose=true)completed.GROUP=Core,allow_reresolve=falsePkg.testinvocation passed all downstream testsets (336 assertions).No ArrayInterface test or downgrade dependency was skipped, weakened, or suppressed.
The proper follow-up is an upstream Resolver patch. This issue records the clean-master failure and fully tested fix while that upstream contribution is coordinated.