Cache was updated by another process warning when using pixi build

[pavelzw]

With pixi-build-python and setup-pixi, i get the following warnings:

[pavelzw]

cc @Hofer-Julian @baszalmstra

[pavelzw]

i could not figure out a minimal reproducer...

[Hofer-Julian]

Pavel managed to make out this reproducer.tar.gz. The only interesting thing I can find is that the Pixi package is used in multiple environments

The warning comes from this part of the code:

pixi/crates/pixi_command_dispatcher/src/source_metadata/mod.rs

Lines 176 to 179 in 3c67703

	source_metadata::WriteResult::Conflict(_) => {
	tracing::warn!(
	"Cache was updated by another process during computation (version conflict), using our computed result"
	);

We have the same log here, but at trace level. I wonder if we the other log should be trace as well

pixi/crates/pixi_command_dispatcher/src/build_backend_metadata/mod.rs

Lines 326 to 329 in 3c67703

	// We use our computed result.
	tracing::debug!(
	"Cache was updated by another process during computation (version conflict), using our computed result"
	);

[mohitdebian]

Opened a PR to address this: the cache version conflict in source_metadata/mod.rs is now logged with debug! instead of warn!, aligning it with the existing behavior in build_backend_metadata/mod.rs.

PR: #5630

[baszalmstra]

Im not sure if changing the logging is correct. If the same packages was used in multiple environments they should have been memoized. So there should not benefit a conflict.

[Hofer-Julian]

Im not sure if changing the logging is correct. If the same packages was used in multiple environments they should have been memoized. So there should not benefit a conflict.

Should we revert the PR then?

[baszalmstra]

The PR is also fine but we should still track this down.

[mohitdebian]

hmm.. that makes sense. If the packages are properly memoized across environments the cache write shouldn’t hit a conflict. I’ll try to reproduce it locally and see what’s triggering the conflict

[mohitdebian]

looking at the code path the conflict seems to happen when multiple environments kick off parallel metadata requests for the same source package since the cache key ends up being identical multiple tasks compute the same metadata concurrently and then race on try_write which gives us the WriteResult::Conflict

The disk cache handles deduplication across runs fine but there doesn't seem to be anything deduplicating in flight requests within a single pixi execution so when environments are solved concurrently identical metadata requests can just run multiple times in parallel.

One way to fix this could be deduplicating inside the CommandDispatcherProcessor something like tracking in flight metadata requests keyed by the cache shard and having them await the same future instead of spawning new ones.

will try to put together a draft PR and see if that holds up.

[mohitdebian]

I’ve opened PR #5647 implementing dispatcher-level deduplication for SourceMetadata requests. This should prevent the concurrent metadata computations that were causing the cache WriteResult::Conflict

[ytausch]

I have found out more details about this issue: The issue occurs exactly if pixi-build is being used and a dot is in the package name.

Minimal reproducer:

pixi.toml

[workspace]
channels = ["conda-forge"]
platforms = ["osx-arm64", "linux-64"]
preview = ["pixi-build"]

[package]
name = "my.package"
version = "0.0.1"
[package.build.backend]
name = "pixi-build-python"
version = "*"
[package.host-dependencies]
python = ">=3.12"
hatchling = "*"
[package.run-dependencies]
python = ">=3.12"

[dependencies]
"my.package" = { path = "." }

pyproject.toml:

[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"

[project]
name = "my-package"
version = "0.0.1"
requires-python = ">=3.12"

my_package/__init__.py: empty file

Commands:

rm -rf .pixi
pixi run python --version

Changing the package name from my.package to my-package makes the warning disappear.