Unable to update marketplace module #1732

We used Claude Desktop with mxcli to update Community commons module, since the version we were using included a vulnerability. At some point I had to provide a pat token to complete the download of the latest version, but it got stuck and failed with the below feedback:

marketplace update --force fails with “open package target.mpk: no such file or directory” after dropping the module

Version: mxcli v0.29.0 (2026-10-30), linux-arm64. MxBuild 11.15.0 set up with mxcli setup mxbuild

What I ran

mxcli marketplace diff 170 -p app.mpr --to 11.5.1
mxcli marketplace update 170 -p app.mpr --to 11.5.1 --force

Community Commons 11.3.0 was installed. 11.5.1 requires Mendix 10.24.0 or later.

Expected: The module is updated to 11.5.1.

Actual:

diff reports no local modifications, but 6 JAR_DEPENDENCY elements are unknown (no DESCRIBE support). Because of that, update refuses without --force. This is expected, but it makes --force necessary for any module that ships jars.
With --force, the update fails:
Updating CommunityCommons 11.3.0 → 11.5.1...
install the new version's bundled files: open package target.mpk: open /tmp/mxu2060897719/target.mpk: no such file or directory

The project may be mid-update — CommunityCommons could be missing. Restore from version control
The failure is destructive. drop module and the unit copy had already run, so the project was left half-updated. Marketplace.mpr and mprcontents/ had changed, with 245 files deleted and new mprcontents/ folders added. I had to restore it with git checkout -- . and git clean.

Downloading the 11.5.1 package with mxcli marketplace download 170 --version 11.5.1 works fine, so the file itself is available.

Observation (hypothesis, not verified): The error path is /tmp/mxu…/target.mpk. In the current source (cmd_marketplace_update.go) the work directory is created with os.MkdirTemp("", "mxupdate"), and target.mpk is expected there after referenceFor. The mxu… prefix therefore doesn’t match the source I looked at (a checkout at 643271e), so the released binary may differ from that source. In any case, target.mpk is not present in the work directory when InstallPackageFiles runs.

Suggestions:

Make sure the package exists in the work directory before drop module runs, so the failure happens before anything is changed.
If a step fails after the drop, roll back, or at least say clearly which state the project is in.
Consider supporting JAR_DEPENDENCY in DESCRIBE, so --force isn’t required for modules that ship jars.