Studio Pro crashes with InvalidOperationException reading mxcli-created BSON

[engalar]

Summary

Studio Pro 11.6.4 crashes with System.InvalidOperationException: Sequence contains no matching element when opening a Mendix 11.6.4 project that has unstaged changes produced by mxcli. The crash occurs during git status computation (RevStatusCache.DoRefresh), specifically when reading the base version of a deleted .mxunit file created by mxcli.

Root Cause Hypothesis

mxcli's BSON writer produces a property name (or nested object property) that does not exist in Studio Pro 11.6.4's type metadata cache. When MprProperty..ctor tries to look up the property definition using ICachedType.Properties.First(predicate), it fails because no matching property is found.

Steps to Reproduce

1. Use mxcli to create microflows in a Mendix 11.6.4 MPR v2 project
2. Commit the changes
3. Use mxcli to DROP MICROFLOW one of the created microflows (creating an unstaged deletion)
4. Open the project in Studio Pro 11.6.4 → crash

Workaround

Commit all unstaged changes before opening Studio Pro, so there is no diff for RevStatusCache to process.

Stack Trace

System.InvalidOperationException: Sequence contains no matching element
   at System.Linq.ThrowHelper.ThrowNoMatchException()
   at System.Linq.Enumerable.First[TSource](IEnumerable`1 source, Func`2 predicate)
   at Mendix.Modeler.Storage.Mpr.MprProperty..ctor(ICachedType containerType, JProperty property) in MprProperty.cs:line 25
   at Mendix.Modeler.Storage.Mpr.MprObject.<>c__DisplayClass5_0.<.ctor>b__2(JProperty p) in MprObject.cs:line 34
   ...
   at Mendix.Modeler.VersionControl.Status.RevStatusCache.CreateDeleteStatusItem(Guid unitID, String baseFilePath)
   at Mendix.Modeler.VersionControl.Status.RevStatusCache.DoRefresh(IProgressInfo info) in RevStatusCache.cs:line 92

Investigation Notes

• The affected unit was 316bfc14-33ff-4678-91c0-80ed806442b8.mxunit, a Microflows$Microflow created by mxcli
• mxcli bson compare shows the top-level Microflow properties match between Studio Pro-created and mxcli-created microflows (0 only-in-left, 0 only-in-right)
• The problematic property is likely in a nested object (action type, data type, or other child element)
• mx check reports 0 errors on the committed project, so the BSON is structurally valid for mx — but Studio Pro's MprProperty constructor is stricter
• Project: Mendix 11.6.4 (MPR v2 format)

TODO

• Write a diagnostic tool that enumerates ALL property names per $Type in a .mxunit file and cross-references them against Studio Pro's expected properties (from reflection data)
• Compare the deleted file's full BSON tree (including nested objects) against a Studio Pro-created microflow with the same action types
• Check if the issue is specific to Mendix 11.x types (mxcli writer was developed primarily against 10.x reflection data)
• Consider adding a mxcli bson validate command that checks property names against the reflection data for the project's Mendix version

[github-actions]

Issue Triage

Summary:
Studio Pro 11.6.4 crashes when opening a project that contains unstaged deletions of .mxunit files created by mxcli, due to a missing property lookup in the BSON data.

Checklist of required bug‑report information

Required info	Present?	Details
mxcli version	❌	Not mentioned
Mendix version	✅	Mendix 11.6.4 (MPR v2)
Scenario (what the user was trying to do)	✅	Creating microflows with mxcli, committing, then dropping a microflow
Expected output	❌	No description of what should have happened (e.g., Studio Pro should open the project without error)
Experienced output	✅	Crash with System.InvalidOperationException: Sequence contains no matching element (stack trace provided)
AI bug report (mxcli diag --bundle or session log)	❌	Not provided

What’s missing:

• The version of mxcli you used (mxcli --version or commit/build info).
• A clear statement of the expected behavior (what should have happened when opening the project).
• An AI bug report bundle (mxcli diag --bundle) or at least the relevant session log from the mxcli run that produced the problematic BSON.

Could you please add those details? Once we have the mxcli version, the expected outcome, and a diagnostic bundle, we’ll be able to investigate the mismatch between mxcli’s BSON writer and Studio Pro’s property lookup. Thanks for the thorough report!

---

Automated triage via OpenRouter — workflow source

[engalar]

Additional Details

mxcli version: v0.3.0-fix-crossassoc (2026-03-30T00:38:11Z) build from https://github.com/engalar/mxcli/tree/fix/cross-association-crash

Expected behavior: Studio Pro should open the project without error, even when there are unstaged changes (deletions/modifications) to .mxunit files created by mxcli. Studio Pro's RevStatusCache should be able to read any valid BSON document to compute git status.

Diagnostic bundle: Generated via mxcli diag --bundle. The session log doesn't capture the specific mxcli run that created the problematic microflow (it was from an earlier session), but the bundle includes project metadata and current state.

Key observation: mx check (Mendix 11.6.4) reports 0 errors on the committed project. This means mx can parse the BSON fine, but Studio Pro's MprProperty..ctor is stricter — it uses First() with a predicate against ICachedType.Properties, which throws when a BSON property name doesn't exist in the type's cached metadata. mx check likely uses a more lenient parser that ignores unknown properties.