pixi install can panic with invalid SlotMap key used when a local path package changes and the lockfile becomes stale #5675
Description
Disclaimer: I originally encountered this panic while working on a confidential monorepo so I used OpenAI Codex to condense it into a small-ish repro and have the following written by Codex as well. Sorry, it's been a long day and I'm tired :)
I ran into a reproducible panic in pixi 0.65.0 when a local path package changes and pixi install has to reconcile that change against an existing stale lockfile.
The panic I see is:
thread '<unnamed>' panicked at crates/pixi_command_dispatcher/src/command_dispatcher_processor/mod.rs:501:56:
invalid SlotMap key used
This pixi-crash-reproducer.zip contains a repro. It's a bit too much for pasting it into the issue text here, so I made a .zip file. Of course, use your own judgement when opening .zip files from strangers on the internet.
How to reproduce:
- Unzip the archive.
cd pixi-crash-reproducer/apps/app1- Run:
rm -rf .pixi
rm -rf /tmp/pixi-crash-reproducer
PIXI_CACHE_DIR=/tmp/pixi-crash-reproducer pixi install
Important detail:
- apps/app1/pixi.lock was generated when packages/pkg1/pyproject.toml had:
pydantic = ">=2.10.7,<3"
- The current packages/pkg1/pyproject.toml now has:
pydantic = ">=2.1.5,<3"
- Despite 2.1.5 being a valid lower bound for pydantic in a technical sense, it has to be noted that there is no actual version 2.1.5 of pydantic. This could also be part of the problem.
So the repro might depend on the lockfile being stale relative to the metadata of a local source package.
This is somewhat race-sensitive:
- in a 20-run check from the final zip, I got 4 panics, 10 cancellation-only runs, and 6 successful runs
- so it is not a guaranteed one-shot repro, but it does hit the panic repeatedly