Skip to content

[Downgrade CI] Resolver crashes on inactive Python_jll LibMPDec_jll compat #499

Description

@ChrisRackauckas-Claude

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions