Partial channel updates may expose inconsistent dependency states during ros-kilted migrations

[han-xudong]

Solution to issue cannot be found in the documentation.

• I checked the documentation.

Issue

Hi, I may be misunderstanding part of the intended release flow, but while looking into dependency conflicts during ros-kilted updates, it seems possible for the channel to briefly expose a partially updated platform state.

This does not seem limited to ros2-distro-mutex. Mutex drift looks like one visible symptom, but the broader issue appears to be that many ROS packages have deep dependency relationships, so publishing only part of a platform update may temporarily produce an inconsistent dependency graph for users.

A downstream mitigation I prototyped locally is to add a per-platform release-readiness gate before upload and to support deferred upload in the build scripts. My current assumption is that the cleaner long-term fix is probably upstream in vinca, with ros-kilted keeping a downstream safeguard. If there is already a preferred way to avoid partial platform publication here, I would appreciate guidance.

Installed packages

N/A for local end-user reproduction. This is a repository release-process issue rather than a single local environment issue.

Environment info

Repository: RoboStack/ros-kilted
Branch: main
Context: repository analysis and local prototype work around per-platform release gating

[Tobias-Fischer]

Hi @han-xudong - thanks for reporting this, and thanks for proposing #69. Could you please be a bit more specific as to:

• What issue you encountered (if possible, please provide a pixi.toml or similar so we can reproduce)
• What the observed behaviour was, and what the desired behaviour would have been
• How Add a per-platform release-readiness gate before upload #69 addressed the problem?

Many thanks,
Tobi

[han-xudong]

Thanks, @Tobias-Fischer. I should have been more concrete.

A concrete example of the kind of problem I meant is intrinsic-dev/aic#463.

In that case, pixi install failed on linux-64 while solving build environments for local ROS path packages. The important part was that the failure was not just “Pixi is broken”, but that the published robostack-kilted metadata on that platform appeared to be temporarily inconsistent around ros2-distro-mutex generations.

At the time I checked, I observed examples like:

• ros-kilted-lifecycle 0.36.4 depending on ros2-distro-mutex 0.13.*
• ros-kilted-ros-core 0.12.0 depending on ros2-distro-mutex 0.13.*
• ros-kilted-ament-cmake 2.7.5 depending on ros2-distro-mutex 0.14.*
• ros-kilted-rosidl-default-generators 1.7.2 depending on ros2-distro-mutex 0.14.*

That meant different parts of the same ROS dependency graph on linux-64 were effectively asking for incompatible mutex generations during the same solve.

So the observed behavior I am trying to describe here is:

• a platform can temporarily expose a partially updated dependency graph during release/migration work

And the desired behavior is:

• the platform should only become visible in its new published state once the required package set for that platform has completed successfully

How #69 relates to this:

• it does not claim to fix the upstream publication model itself
• it adds a downstream safeguard so local/CI upload flows can validate whether a platform output set is complete before publishing
• it also adds support for deferred upload in the build scripts, so downstream workflows can build first and only publish later

My current understanding is still that the cleaner long-term fix is upstream in the workflow generator/publish model, with ros-kilted keeping a downstream safeguard.

[Tobias-Fischer]

Hmm that’s interesting! I thought that the pixi solver would deal with issues like this - any input @wolfv?