Studio Pro F4 Crash — `Sequence contains no matching element` When Syncing After mxcli Changes

[brfreek-tof]

Environment

Component	Version / Detail
Mendix Studio Pro	11.8.0.0
mxcli	v0.2.0-dirty (built 2026-03-15T09:22:47Z)
OS	macOS (Eto.Forms stack trace confirms Mac build)
Project	Mendix app using git-backed .mpr + mprcontents/ layout
Trigger action	F4 (Project → Synchronize from disk)

---

Summary

After mxcli exec applies MDL changes to a project, Mendix Studio Pro 11.8.0.0 crashes with System.InvalidOperationException: Sequence contains no matching element whenever the user presses F4 to sync the project from disk.

The crash occurs in Studio Pro's version control status cache while it tries to parse the git-tracked (pre-mxcli) base version of .mxunit files that mxcli deleted. A JSON property in one of those files is not recognized by the Studio Pro 11.8.0.0 type schema, causing Enumerable.First(predicate) to throw because no element matches.

---

Reproduction Steps

1. Run ./mxcli exec <script>.mdl -p "Project.mpr" to apply MDL changes.
2. Commit all changes: git add -A && git commit -m "chore: mxcli changes".
3. Open the project in Studio Pro 11.8.0.0 (working tree is clean at this point).
4. Make any structural change inside Studio Pro — e.g., delete a microflow.
5. Press F4 (Synchronize from disk).
6. Result: Studio Pro crashes with the exception below. The microflow disappears but an error dialog is shown. Studio Pro must be restarted.
7. Expected: Studio Pro syncs cleanly and shows the updated model.

Minimal trigger: Deleting any document (microflow, page, etc.) in Studio Pro whose .mxunit file in git HEAD was written by mxcli, then pressing F4.

---

Full 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 Mendix.Modeler.Storage/Mpr/MprProperty.cs:line 25
   at Mendix.Modeler.Storage.Mpr.MprObject.<>c__DisplayClass5_0.<.ctor>b__2(JProperty p) in Mendix.Modeler.Storage/Mpr/MprObject.cs:line 34
   at System.Linq.Enumerable.IEnumerableWhereSelectIterator`2.MoveNext()
   at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
   at Mendix.Modeler.Storage.Mpr.MprObject..ctor(JObject data) in Mendix.Modeler.Storage/Mpr/MprObject.cs:line 42
   at Mendix.Modeler.Storage.Mpr.MprUnit.get_Contents() in Mendix.Modeler.Storage/Mpr/MprUnit.cs:line 70
   at Mendix.Modeler.VersionControl.Status.RevStatusCache.ExtractUnitInfo(MprUnit mprUnit, Type& unitType, String& unitName, Guid& containerID)
   at Mendix.Modeler.VersionControl.Status.RevStatusCache.CreateDeleteStatusItem(Guid unitID, String baseFilePath)
   at Mendix.Modeler.VersionControl.Status.RevStatusCache.CreateStatusItem(DiffItem diff, Dictionary`2 unitDict, String baseFilePath, String mineFilePath)
   at Mendix.Modeler.VersionControl.Status.RevStatusCache.AddStatusItems(IEnumerable`1 diffs, Dictionary`2 unitDict, String baseFilePath)
   at Mendix.Modeler.VersionControl.Status.RevStatusCache.DoRefresh(IProgressInfo info)
   at Mendix.Modeler.VersionControl.Status.StatusCacheManager.RefreshAll(IProgressInfo info)
   at Mendix.Modeler.VersionControl.Status.StatusCacheManager.ProjectManagerOnProjectFileChanged(Object sender, ProjectFileChangedEventArgs e)
   at Mendix.Modeler.Core.ProjectManager.RaiseProjectFileChanged(IProgressInfo info)
   at Mendix.Modeler.Main.FileSystems.CoreFileSystemPlugin.Synchronize(IProject project, SynchronizeMode mode)
   at Mendix.Modeler.Main.FileSystems.FileSystemPluginRegistry.<>c__DisplayClass11_0.<Synchronize>b__0(IFileSystemPlugin plugin)
   at System.Linq.Enumerable.All[TSource](IEnumerable`1 source, Func`2 predicate)
   at Mendix.Modeler.Main.FileSystems.FileSystemPluginRegistry.Synchronize(IProject project, SynchronizeMode mode)
   at Mendix.Modeler.Main.FileSystems.FileSystemPluginRegistry.ExecuteSynchronizeStepAction(Func`1 getProject, SynchronizeMode mode, IProgressInfo info)
   at Mendix.Modeler.Main.FileSystems.FileSystemPluginRegistry.<>c__DisplayClass10_0.<AddSynchronizeStep>b__0(IProgressInfo info)
   at Mendix.Modeler.Utility.Progress.StepBase`1.Run(TProgressInfo info) in Mendix.Modeler.Utility/Progress/Step.cs:line 32
   at Mendix.Modeler.Utility.Progress.StepBase`1.Mendix.Modeler.Utility.Progress.IStep.Run(Object progressInfo) in Mendix.Modeler.Utility/Progress/Step.cs:line 37
   at Mendix.Modeler.UIFramework.Progress.ProcessRunner.RunStep(IStep step) in Mendix.Modeler.UIFramework/Progress/ProcessRunner.cs:line 240
   at Mendix.Modeler.UIFramework.Progress.ProcessRunner.OnDoWork(Object sender, DoWorkEventArgs e) in Mendix.Modeler.UIFramework/Progress/ProcessRunner.cs:line 157
   at Mendix.Modeler.Undo.UndoDelegatingBackgroundWorker.OnDoWork(DoWorkEventArgs e) in Mendix.Modeler.Undo/UndoDelegatingBackgroundWorker.cs:line 22
   at System.ComponentModel.BackgroundWorker.WorkerThreadStart(Object argument)
--- End of stack trace from previous location ---
   at Mendix.Modeler.UIFramework.Progress.ProcessRunner.Run() in Mendix.Modeler.UIFramework/Progress/ProcessRunner.cs:line 108
   at Mendix.Modeler.Main.FileSystems.FileSystemPluginRegistry.LaunchSynchronizeProcess(IProject project)
   at Mendix.Modeler.MainWindow.Menus.MenuItemsProviders.ProjectMenuDirectoryMenuItemsProvider.<>c__DisplayClass5_0.<.ctor>b__0()
   at Eto.Forms.RelayCommand.<>c__DisplayClass0_0.<.ctor>b__0(Object obj)
   at Eto.Forms.RelayCommand`1.Execute(Object parameter)
   at Eto.PropertyStore.CommandWrapper.Command_Execute(Object sender, EventArgs e)
   at Eto.Forms.Command.OnExecuted(EventArgs e)
   at Mendix.Modeler.Controls.Menus.AsyncInvokedCommand.<>n__0(EventArgs e)
   at Mendix.Modeler.Controls.Menus.AsyncInvokedCommand.<>c__DisplayClass2_0.<OnExecuted>b__0() in Mendix.Modeler.Controls/Menus/MenuItemViewModel.cs:line 192
   at Mendix.StudioPro.MacOS.StudioProApplicationHandler.ActionWrapper.PerformAction()

---

Affected File (from git working tree)

This .mxunit file was deleted by Studio Pro when the user deleted a microflow. It was originally written to git HEAD by mxcli:

File	Notes
mprcontents/a9/19/a919747b-fc45-4ff3-aec7-540195b228e0.mxunit	Deleted by Studio Pro in-session; git HEAD version written by mxcli

The crash happens when Studio Pro reads the git HEAD (base) version of this file to populate the VCS status panel — not the working-tree (deleted) version.

---

Root Cause Analysis

The call chain is:

RevStatusCache.CreateDeleteStatusItem
  → reads base (git HEAD) .mxunit file for the deleted document
  → MprUnit.get_Contents() deserializes it
  → MprObject..ctor iterates each JProperty in the JSON blob
  → MprProperty..ctor(ICachedType containerType, JProperty property)
       calls containerType.Properties.First(p => p.Name == property.Name)
       ← THROWS: no property with that name exists in the schema

The problematic line is MprProperty.cs:25, which uses Enumerable.First() — a hard throw when no match is found. If an .mxunit file in git HEAD contains any property name not in Studio Pro's type registry, the F4 sync crashes.

Root cause: mxcli schema mismatch persists in git history

mxcli v0.2.0 writes .mxunit files using a model schema that differs from Mendix 11.8.0.0's expected schema. Once those files are committed, they remain in git HEAD. Any subsequent deletion of those files — whether by mxcli or by the user inside Studio Pro — will trigger this crash the next time Studio Pro refreshes its VCS status.

This means:

• Committing mxcli changes before opening Studio Pro does not prevent the crash.
• The crash is not limited to mxcli-deleted files in the working tree.
• Every user edit inside Studio Pro that touches an mxcli-authored .mxunit file (delete, move, rename) is a potential trigger.

Secondary issue: Studio Pro defensive coding gap

Studio Pro's MprProperty..ctor uses .First() instead of .FirstOrDefault(). Even in a legitimate forward-compatibility scenario (unknown property from a newer schema), this causes a hard crash rather than graceful handling. This is a Studio Pro bug that amplifies the impact of the mxcli schema mismatch.

---

Workaround

Note: The original workaround (commit before opening Studio Pro) is insufficient. The crash occurs because git HEAD contains mxcli-written .mxunit files with unknown properties. Committing does not remove those files from git history — it just changes who holds the working-tree deletion. Any Studio Pro edit that deletes an mxcli-authored .mxunit file will still crash on F4.

Until fixed, the practical options are:

1. Avoid VCS features in Studio Pro entirely while working on an mxcli-authored project. Do not press F4, do not open the VCS status panel, do not diff deleted documents.
2. Do all structural edits in Studio Pro first (before any mxcli session), commit those from Studio Pro's own VCS tools, then switch to mxcli. Avoid interleaving Studio Pro structural edits with mxcli sessions on the same files.
3. Use mxcli exclusively for all model changes and never delete/rename documents in Studio Pro after an mxcli session has touched those files.

---

Recommended Fixes

For the mxcli developer

1. Audit the schema version used when writing .mxunit files. Confirm that all properties serialised into mprcontents/*.mxunit files match the property names in the target Mendix version's type registry (Mendix 11.8.0.0 in this case).

2. Consider writing a .mxunit schema compatibility test: after exec, read back each written .mxunit file and verify all JSON keys are in the expected schema. This would catch this class of bug before the user hits F4.

3. Document the known limitation: if mxcli intentionally uses a different schema (e.g., it targets a newer or older Mendix model version), the README or release notes should warn users that F4 sync in Studio Pro will crash until changes are committed/stashed.

For the Mendix Studio Pro team (secondary)

In MprProperty.cs:25, replace:

// Current (crashes on unknown property):
var typedProp = containerType.Properties.First(p => p.Name == property.Name);

with:

// Suggested (graceful handling):
var typedProp = containerType.Properties.FirstOrDefault(p => p.Name == property.Name);
if (typedProp == null)
{
    // Log warning and skip unknown property — don't crash VCS status refresh
    Logger.Warn($"Unknown property '{property.Name}' on type '{containerType.Name}' — skipping.");
    return;
}

This would make Studio Pro resilient to schema mismatches from external tools (mxcli, migration scripts, etc.) and prevent a full crash on F4.

---

Additional Context

• All mxcli changes were committed before Studio Pro was opened. The crash was triggered by a Studio Pro-initiated deletion (user deleting a microflow in Studio Pro), not by mxcli-deleted files in the working tree.
• The crash is reproducible whenever: (a) git HEAD contains .mxunit files written by mxcli, and (b) the user deletes any such document inside Studio Pro and then presses F4.
• The scope is broader than originally assessed: it applies to any .mxunit file authored by mxcli and present in git HEAD, not just folder container units (Projects$Folder). Microflow units, page units, and others are all candidates.

[brfreek-tof]

Updated the description due to some incorrect assumptions

[brfreek-tof]

Root cause identified — ConcurrenyErrorMessage property name typo in serialized .mxunit output

After deeper investigation we have a precise root cause for the Studio Pro F4 crash reported above.

mxcli v0.2.0 writes ConcurrenyErrorMessage (missing the second c) in every .mxunit file it serialises for microflow units. The correct property name expected by Mendix Studio Pro 11.8.0.0
is ConcurrencyErrorMessage. Because MprProperty..ctor (line 25) uses Enumerable.First() rather than FirstOrDefault(), any encounter with the unknown property name throws
System.InvalidOperationException: Sequence contains no matching element — crashing the VCS status refresh triggered by F4 (Synchronize from disk).

The crash fires specifically when:

1. A .mxunit file authored by mxcli exists in git HEAD, and
2. The user deletes the corresponding document inside Studio Pro, then
3. Presses F4 — Studio Pro reads the git HEAD version of the deleted file to populate the VCS status panel and crashes.

Files that still exist in the working tree are unaffected; the crash is limited to the "deleted vs. HEAD" diff path in RevStatusCache.CreateDeleteStatusItem.

Scope: Every microflow unit written by mxcli v0.2.0 carries this typo. In our case 41 .mxunit files were affected.

Workaround applied (project side):
Fixed the property name in all 41 affected .mxunit files with a text substitution (ConcurrenyErrorMessage → ConcurrencyErrorMessage) and committed. Studio Pro reads the corrected JSON on
the next F4 sync.

Secondary consequence discovered: When Studio Pro crashes during an active F4 sync it can leave the .mpr BSON in a truncated state (Read past end of current container context. Path
'WorkflowActionInfo'), making the project unopenable until the .mpr is restored from a pre-crash git snapshot.

[brfreek-tof]

⚠️ Correction to previous comment — DO NOT attempt text replacement on .mxunit files

After further investigation: the "project-side workaround" described in my previous comment is incorrect and dangerous. I made the same mistake.

.mxunit files in Mendix V2 git storage are BSON binary, not plain UTF-8 text. In Mendix V2, the .mpr SQLite database stores only unit IDs and metadata — the actual unit content is stored
in .mxunit files as BSON blobs, read at open time via MprV2UnitRepository.LoadUnitContentsFile. Running sed or any text replacement on these files changes string byte lengths without
updating the BSON length prefixes, producing Read past end of current container context errors that prevent the project from opening at all.

Corrected understanding of the storage model:

• .mpr — SQLite, unit ID/metadata index only
• mprcontents/*.mxunit — BSON binary, actual unit content (read directly from disk on project open)
• Any fix to the ConcurrenyErrorMessage typo in .mxunit files must use a BSON-aware tool that rewrites both the string value and all affected length prefixes

Recovery if you already ran text replacement:
Restore all modified .mxunit files from git: git checkout -- mprcontents/

For mxcli maintainers: The typo fix must be applied in the microflow unit serialiser using whatever BSON library mxcli uses internally — not as a post-processing text patch. The fix also
needs to update the document-level and string-level BSON length fields consistently.

[ako]

Can you try with a recent build, preferably the nightly build

[ako]

Investigation Results

Thanks for the detailed report! We investigated the root cause against Studio Pro 11.6.3 and 11.8.0 reference projects.

ConcurrenyErrorMessage is NOT a typo

We extracted the top-level BSON keys from microflow .mxunit files created by Studio Pro itself in both 11.6.3 and 11.8.0 projects. Both use the exact same spelling:

ConcurrencyErrorMicroflow   ← correct spelling
ConcurrenyErrorMessage      ← Mendix's own storage name (missing second 'c')

This matches the Mendix reflection data (concurrenyErrorMessage in the 11.6.0 structures). So the typo originates from Mendix, and mxcli correctly uses the same spelling. This is not the cause of the crash.

Likely real cause: Pages$Page vs Forms$Page unit type mismatch

In mxcli v0.2.0, CreatePage and CreateLayout wrote the unit type as Pages$Page / Pages$Layout in the SQLite database, but Studio Pro expects Forms$Page / Forms$Layout (the historical "Form" naming convention). When Studio Pro's MprProperty..ctor loads a unit from git HEAD with an unrecognized $Type, it calls .First() on the type registry and throws — exactly the Sequence contains no matching element crash in your stack trace.

This was fixed in commit 5f6495b (March 21, 2026).

Many BSON fixes since v0.2.0

There have been 22 writer fixes since your v0.2.0-dirty build (March 15), including:

• 5f6495b — Fix Pages$Page → Forms$Page unit type mismatch
• 88dad1d — Fix Long type written as IntegerType instead of LongType
• b6f7c6f — Fix DateTime roundtrip
• 743138b — Fix VIEW entity types, constant value BSON
• Multiple workflow, image collection, and other BSON serialization fixes

Recommendation

Please try a recent build (nightly or build from main). If you can still reproduce after updating, please let us know — but we believe the Forms$ prefix fix resolves this specific crash.

⚠️ Also confirming your correction: .mxunit files are BSON binary, not UTF-8 text. Running sed or text replacement on them will corrupt the BSON length prefixes. Any property-level fix must go through a BSON-aware tool.

[brfreek-tof]

Updated to 0.3.0 and following findings:

Environment

• Mendix Studio Pro: 11.8.0.0 (macOS)
• mxcli: v0.3.0-dirty (linux-arm64, built 2026-03-26T06:10:24Z)
• Project format: Mendix V2 git layout (.mpr + mprcontents/*.mxunit)

---

Summary

The same MprProperty..ctor — Sequence contains no matching element crash from issue #46 still occurs in mxcli v0.3.0 when Studio Pro reads a folder unit that mxcli wrote to git HEAD. The crash fires immediately when deleting the folder in Studio Pro — not only on F4.

Pages and microflows recreated with v0.3.0 do not trigger this crash. The issue appears specific to folder units.

---

Reproduction Steps

1. Create a microflow with a FOLDER clause via mxcli exec:

   CREATE OR REPLACE MICROFLOW Module."TEMP" ()
   RETURNS Boolean
   FOLDER 'SomeFolder'
   BEGIN RETURN false; END;
   

2. Drop the microflow:

   DROP MICROFLOW Module."TEMP";
   

   The folder unit for SomeFolder remains as a file in mprcontents/ (mxcli does not clean up empty folder units on DROP).

3. Commit the remaining folder unit to git.

4. Open the project in Studio Pro 11.8.0.0.

5. Delete the empty SomeFolder folder in the App Explorer.

Result: Studio Pro crashes immediately.

---

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 Mendix.Modeler.Storage/Mpr/MprProperty.cs:line 25
   at Mendix.Modeler.Storage.Mpr.MprObject.<>c__DisplayClass5_0.<.ctor>b__2(JProperty p) in Mendix.Modeler.Storage/Mpr/MprObject.cs:line 34
   at System.Linq.Enumerable.IEnumerableWhereSelectIterator`2.MoveNext()
   at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
   at Mendix.Modeler.Storage.Mpr.MprObject..ctor(JObject data) in Mendix.Modeler.Storage/Mpr/MprObject.cs:line 42
   at Mendix.Modeler.Storage.Mpr.MprUnit.get_Contents() in Mendix.Modeler.Storage/Mpr/MprUnit.cs:line 70
   at Mendix.Modeler.VersionControl.Status.RevStatusCache.ExtractUnitInfo(MprUnit mprUnit, Type& unitType, String& unitName, Guid& containerID)
   at Mendix.Modeler.VersionControl.Status.RevStatusCache.CreateDeleteStatusItem(Guid unitID, String baseFilePath)
   at Mendix.Modeler.VersionControl.Status.RevStatusCache.CreateStatusItem(DiffItem diff, Dictionary`2 unitDict, String baseFilePath, String mineFilePath)
   at Mendix.Modeler.VersionControl.Status.RevStatusCache.AddStatusItems(IEnumerable`1 diffs, Dictionary`2 unitDict, String baseFilePath)
   at Mendix.Modeler.VersionControl.Status.RevStatusCache.DoRefresh(IProgressInfo info)
   at Mendix.Modeler.VersionControl.Status.StatusCacheManager.RefreshAll(IProgressInfo info)
   at Mendix.Modeler.VersionControl.Status.StatusCacheManager.ProjectManagerOnProjectFileChanged(Object sender, ProjectFileChangedEventArgs e)
   at Mendix.Modeler.Core.ProjectManager.RaiseProjectFileChanged(IProgressInfo info)
   at Mendix.Modeler.Common.Deleter.DoDeleteUnit(IStorageUnit unit, IIdentifiable identifiable, Action removeFromModel, Func`1 confirmDelete, Boolean raiseEvents, IProgressInfo info)
   at Mendix.Modeler.Common.Deleter.DeleteUnidentifiableUnit(IStorageUnit unit, Action removeFromModel, Func`1 confirmDelete)
   at Mendix.Modeler.ProjectHandling.View.ExplorerOperations.DeleteFolder(IConcreteFolder subject)
   at Mendix.Modeler.WebToolWindows.AppExplorer.AppExplorerViewModel.HandleEditAction(EditAction editAction)

---

Key Observations

Crash trigger: CreateDeleteStatusItem reads the folder unit from git HEAD (baseFilePath) when Studio Pro detects the unit was deleted from the working tree. Studio Pro cannot parse the folder unit BSON at that point.

v0.3.0 does not fix this: We verified by creating a fresh folder unit with v0.3.0, committing it, then deleting it in Studio Pro — same crash.

bson dump does not support folders: mxcli bson dump --type folder is not a supported type, so the folder unit BSON content cannot be inspected using mxcli's own tooling.

No DROP FOLDER command: Once an empty folder unit is committed to git HEAD, there is no mxcli command to remove it. The only workaround is to rename the folder in Studio Pro, save, commit the rewritten unit, then delete — so git HEAD has Studio Pro-written BSON before the delete status item is created.

---

[ako]

Follow-up: Folder unit investigation

Thanks for the updated reproduction steps with v0.3.0. We did a deep investigation of the folder unit BSON.

Folder BSON is byte-for-byte identical to Studio Pro

We reproduced your exact scenario (CREATE MICROFLOW with FOLDER clause → DROP MICROFLOW → orphaned folder unit remains) and compared the mxcli-generated folder .mxunit against Studio Pro 11.8.0-created folder units:

• Same fields: $ID (binary, subtype 0x00, 16 bytes), $Type ("Projects$Folder"), Name
• Same field order: $ID, $Type, Name
• Same BSON encoding: byte-for-byte identical when using the same ID and name values
• Same SQLite metadata: ContainmentName = "Folders", same schema

We cannot reproduce a BSON-level difference that would trigger MprProperty..ctor to fail on a Projects$Folder unit.

Questions to narrow this down

1. Which build exactly? You mentioned v0.3.0-dirty — the -dirty flag means you have local modifications. Could you try with a clean release build, or share which changes you have?

2. Can you share the problematic .mxunit file? Running xxd mprcontents/XX/YY/<folder-uuid>.mxunit | head -10 on the folder unit that triggers the crash would let us compare directly.

3. Is the folder nested? Does FOLDER 'SomeFolder' or FOLDER 'Parent/Child' make a difference? Nested folders create multiple folder units.

4. Does it crash with a fresh project? If you create a brand new Mendix 11.8.0 project, run mxcli to create a microflow with a FOLDER clause, commit, open in Studio Pro, and delete the folder — does it still crash?

Orphaned folder cleanup

You're right that DROP MICROFLOW leaves orphaned empty folders behind, and there's no DROP FOLDER command. This is a separate issue worth tracking — the orphaned folder unit itself shouldn't cause a crash (it's valid BSON), but it is untidy. We can look into adding automatic cleanup of empty folders on DROP.

[ako]

Drop folder and move folder commands have been implemented.