[Downgrade CI] Resolver crashes on inactive Python_jll LibMPDec_jll compat

julia-downgrade-compat/downgrade.jl と Registries.jl:224 周辺の Resolver 互換性 shim から始め、ドキュメント化された Julia 1.10 コマンドを使って失敗を再現します。次に bin/test/runtests.jl と Resolver の Pkg.test を実行します。downgrade コマンドと downstream のワークフロー相当テストが、カバレッジをスキップせずに成功すれば完了です。

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.

• Current clean-master failure: d767284, run 30054476628, job 89363223986
• First clean-master failure: run 27407002673, job 80998509723, June 12
• Last green run: run 27149028395, job 80134716100, June 8, at db587545

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.