Microflow call parameter mappings can be written with invalid BSON field order

[hjotha]

Summary

Some microflow call activities can roundtrip textually but become invalid after mxcli exec. Studio Pro reports CE0117 expression errors on the call activity even though the MDL source is unchanged.

Expected behavior

Serializing a MicroflowCallAction should preserve the BSON field order Studio Pro expects for:

• the top-level MicroflowCallAction
• the nested MicroflowCall
• each MicroflowCallParameterMapping

Actual behavior

The writer emits result-variable fields before the nested call, QueueSettings before parameter mappings, and mapping fields as Parameter before Argument. This can produce a model that loads but fails validation with an expression error on the call activity.

Proposed fix

Emit the call payload in the same stable order as Studio Pro writes it: nested MicroflowCall before result fields, ParameterMappings before QueueSettings, and mapping Argument before Parameter.

Related

Part of the broader microflow roundtrip validity tracker #332.

[github-actions]

Issue Triage

Summary:
The issue reports that mxcli exec can reorder BSON fields in MicroflowCallAction elements, causing Studio Pro to show CE0117 expression errors even though the MDL source appears unchanged.

Checklist for bug report completeness

Required info	Present?	Details
mxcli version	❌	Not mentioned
Mendix version	❌	Not mentioned
Scenario (what command/MDL script was run)	⚠️	Mentions mxcli exec but no exact command or project details
Expected output	✅	Describes that field order should match Studio Pro’s order
Experienced output	⚠️	Notes Studio Pro CE0117 errors after mxcli exec; no explicit error output from mxcli or log shown
AI bug report (mxcli diag --bundle or session log)	❌	Not provided

What’s missing:
Please add the following information so we can reproduce and investigate the problem:

1. The exact version of mxcli you’re using (mxcli --version or commit/build hash).
2. The Mendix version of the project you’re processing (e.g., 10.6.0, 9.24.1).
3. The precise command you ran (including any arguments) and a brief description of the project or MDL snippet involved.
4. The full error output you saw from mxcli exec (or the Studio Pro error log) and, if possible, the session log from mxcli diag --bundle.

Once we have those details, we’ll be able to look into the field‑ordering issue. Thanks for bringing this to our attention!

---

Automated triage via OpenRouter — workflow source