CREATE OR MODIFY MICROFLOW with attribute CHANGE corrupts MPR (invalid AttributeIdentifier); passes all mxcli checks but Studio Pro won't open

[Chendodelangen]

Summary

CREATE OR MODIFY MICROFLOW silently corrupts the .mpr when the microflow body contains an object attribute CHANGE (or CREATE with attribute assignments). The attribute is serialized as a plain string instead of a valid AttributeIdentifier. All mxcli validation (check, check --references, lint, exec) passes, but Studio Pro then refuses to open the project.

Association CHANGE (e.g. CHANGE $X (Module.Assoc = $Y)) serializes fine — only attribute references break.

Environment

• mxcli version: v0.11.0 (2026-05-21T18:04:46Z)
• Mendix version: 10.24.15.93102
• Diagnostic bundle available: yes — mxcli-diag-20260601-131705.tar.gz

Steps to reproduce

Take any existing microflow that sets an attribute and re-create it via MDL:

CREATE OR MODIFY MICROFLOW MyModule.TestFlow (
  "$Obj": MyModule.SomeEntity
)
BEGIN
  CHANGE $Obj (SomeAttribute = 'value');
  RETURN;
END;
/

1. mxcli check script.mdl -p App.mpr --references → passes
2. mxcli lint -p App.mpr → passes
3. mxcli exec script.mdl -p App.mpr → reports Replaced/Created microflow successfully
4. Open the project in Studio Pro

Expected behaviour

The CHANGE activity stores a valid AttributeIdentifier for SomeAttribute, and the project opens normally.

Actual behaviour

Studio Pro refuses to open the project:

It is not possible to open the project file '...mpr', because it has an invalid format.
Usually this issue is caused by setting invalid property values in the project with the Mendix Model SDK.

Change in microflow 'MyModule.TestFlow' has an invalid value 'SomeAttribute' for property Attribute.
The text 'SomeAttribute' is not a valid AttributeIdentifier.
   at Mendix.Modeler.DomainModels.AttributeIdentifier.FromString(String text)

mxcli never flags this — the corruption only surfaces in Studio Pro.

Impact

• Silent corruption: the tooling reports success, so it is only discovered when a developer next opens Studio Pro.
• Recovery requires restoring the model from version control (the model is MPR v2 / mprcontents/*.mxunit).

Secondary observation (possibly related / separate issue)

CREATE OR MODIFY MICROFLOW on an existing microflow assigns new GUIDs to its parameters. Every caller that maps those parameters (e.g. action buttons / data views on pages calling the microflow) then breaks with CE1613 "The selected parameter '...' no longer exists.". This makes it risky to edit any microflow that already has callers. If intended, documenting it (and/or preserving parameter identities on modify) would help.

Workaround

Perform all object creation / attribute mutation in a Java action (Core API instantiate / setValue resolve members at runtime, so nothing invalid is stored), and avoid CREATE OR MODIFY MICROFLOW on microflows that contain attribute CHANGE/CREATE or that already have callers.

[github-actions]

Issue Triage

Summary:
The CREATE OR MODIFY MICROFLOW command incorrectly serializes attribute CHANGE/CREATE statements as plain strings instead of proper AttributeIdentifier objects, causing Studio Pro to reject the project even though all mxcli validation passes.

Checklist for bug report completeness

Required info	Present?	Details
mxcli version	✅	v0.11.0 (2026-05-21T18:04:46Z)
Mendix version	✅	10.24.15.93102
Scenario (what the user was trying to do)	✅	MDL script with CREATE OR MODIFY MICROFLOW containing CHANGE $Obj (SomeAttribute = 'value')
Expected output	✅	Valid AttributeIdentifier stored; project opens in Studio Pro
Experienced output (error/wrong result)	✅	Studio Pro refuses to open; error: “The text 'SomeAttribute' is not a valid AttributeIdentifier.”
AI bug report (diagnostic bundle or session log)	✅	Diagnostic bundle available: mxcli-diag-20260601-131705.tar.gz

Conclusion:
All required information for a bug report is present. Thank you for the detailed issue!

---

Automated triage via OpenRouter — workflow source

[Chendodelangen]

Related third finding: quoted parameter name with $ produces $$name and breaks variable binding (CE0109), undetected by check/lint

While working around the CHANGE corruption above by moving logic into Java actions, a separate (related) serialization issue surfaced.

Declaring a microflow parameter with the name quoted including the $ — e.g. "$Object": MyModule.Entity — causes mxcli to store the parameter name as $Object (round-trips/displays as $$Object). The microflow body's $Object reference then resolves to a variable named Object, which does not exist, so Studio Pro reports:

• CE0109 Undefined variable 'Object' on every activity that uses the parameter, and
• CW0094 Variable '$Object' is never used on the parameter itself.

-- Produces $$Object (broken binding)
CREATE OR MODIFY MICROFLOW MyModule.Handler ( "$Object": MyModule.Entity )
RETURNS Boolean AS $Allow
BEGIN
  $X = $Object/SomeAttr;   -- CE0109 in Studio Pro
  RETURN true;
END;
/

-- Correct: parameter unquoted (or quoted WITHOUT the $)
CREATE OR MODIFY MICROFLOW MyModule.Handler ( $Object: MyModule.Entity ) ...

This may be partly user error (over-applying an "always quote identifiers" guideline to parameter names), but two things make it sharp:

1. mxcli check / check --references / lint all pass on the broken model — the mismatch only appears when Studio Pro opens the project.
2. mxcli silently accepts a $ inside a quoted parameter name and bakes it into the identifier.

Suggestion: reject/normalize a leading $ in quoted parameter names, or flag the unbound-variable mismatch during check.

Environment unchanged: mxcli v0.11.0 (2026-05-21T18:04:46Z), Mendix 10.24.15.93102.