Business Rule call inside an expression loses its Condition/Value on Mendix 11 (works on Mendix 10)

[WouterHooglandTOF]

mxcli bug: Business Rule call inside an expression loses its Condition/Value on Mendix 11 (works on Mendix 10)

mxcli version

nightly-20260820-766cdf62 (2026-08-20T09:13:49Z)

Mendix version

11.12.3. The identical MDL text, applied to the identical microflow via create or modify microflow, does not reproduce on Mendix 10.24.20.105674 — this appears Mendix-11-specific (or specific to how this mxcli version's writer targets Mendix 11's model format for this element type).

Severity

High. No parse error, no warning, no non-zero exit code from exec — the script reports success (Replaced microflow: ...). The corruption is silent and only surfaces later via mx check/docker check, or at runtime. Any microflow that calls a Business Rule inside a decision condition or a variable assignment, and gets rewritten via create or modify microflow, silently loses that call.

Summary

A Mendix "Business Rule" (Decision document) called directly inside an expression — either as a decision's condition (IF Module.SomeRule(Param = $Value) THEN ...) or as the right-hand side of a variable assignment (SET $Var = Module.SomeRule(Param = $Value);) — round-trips through describe microflow as plausible-looking MDL text, but writing that same text back via create or modify microflow produces a microflow whose actual model object has no real Condition/Value for that activity. mx check then fails on load with:

• Decision form: [CE0080] "The 'Condition' property is required." at the Decision activity.
• Variable-assignment form: [CE0117] "Error(s) in expression." at the Change Variable activity.

Both are the same underlying defect (the writer cannot reconstruct a real reference to the Rule/Decision document from this call syntax on Mendix 11), just surfacing as two different downstream symptoms depending on where the call sits.

Worse: after the corruption, describe microflow on the decision-form case shows the condition as if true then, with the original @caption text still showing the real rule call — i.e. the tool's own round-trip view actively misrepresents the broken state as a harmless-looking true, giving no visual indication anything is wrong short of running a full mx check.

Steps to reproduce (project-independent)

Requires an actual Mendix Business Rule (not a microflow) — this is what makes the repro non-trivial to shrink further, since Rules aren't a describe/create-able element type in mxcli (mxcli describe --help lists no rule type at all; mxcli describe microflow Module.SomeRule returns microflow not found). Create the Rule once in Studio Pro, then everything else is mxcli/MDL:

1. In Studio Pro, create a trivial Business Rule Sample.Rule_IsActive with one Boolean input parameter IsActive and body return $IsActive; (or any simple pass-through). Save.
2. Create a microflow that calls it inline as a decision condition:

   create microflow Sample.ACT_Order_Process (
     $IsActive: Boolean
   )
   folder 'Pages/Order'
   begin
     if Sample.Rule_IsActive(IsActive = $IsActive) then
       return;
     else
       return;
     end if;
   end;
   /

3. Verify clean: mxcli docker check -p sample.mpr → 0 errors.
4. Re-apply the exact same create or modify microflow statement (simulating any later edit that touches this microflow, e.g. adding an unrelated activity elsewhere in the same flow — the whole body gets rewritten either way since create or modify is a full replace).
5. Run mxcli docker check -p sample.mpr again.

Expected behaviour

Step 5 still reports 0 errors — rewriting a microflow that calls a Business Rule in a condition should preserve that call exactly, since nothing about the call itself changed.

Actual behaviour (verbatim from my session, generalized names)

• After replaying create or modify microflow Module.ACT_MiniCompetitie_OpenVoornemenTotGunnenConfirmation_Prijs (...) whose body's first activity was if Module.Rule_MiniCompetitie_StatusInBehandeling(MiniCompetitie = $MiniCompetitie) then, mxcli exec reported success. mxcli docker check then failed:

  [error] [CE0080] "The 'Condition' property is required." at Decision 'Module.Rule_MiniCompetitie_StatusInBehandeling(MiniCompetitie = $MiniCompetitie)'
  

• mxcli describe microflow on the now-broken microflow showed the decision's condition as if true then, while its @caption still read 'Module.Rule_MiniCompetitie_StatusInBehandeling(MiniCompetitie = $MiniCompetitie)' — the caption (cosmetic label) survived, the actual condition object did not.
• As a workaround attempt, I moved the same rule call out of the decision into a preceding variable assignment instead:

  declare $InBehandeling Boolean = false;
  set $InBehandeling = Module.Rule_MiniCompetitie_StatusInBehandeling(MiniCompetitie = $MiniCompetitie);
  if $InBehandeling then ...

  This applied without a write-time error, but mxcli docker check then failed differently:

  [error] [CE0117] "Error(s) in expression." at Change variable activity 'Change variable InBehandeling'
  

• mxcli callers Module.Rule_MiniCompetitie_StatusInBehandeling reports no callers found, even while the (broken) call is textually present in describe microflow output for two other microflows — consistent with the reference never being properly resolved/bound in the model, in either call form.
• The identical create or modify microflow MDL text, applied earlier in the same session to the same microflow on a Mendix 10.24.20.105674 copy of the same app, produced no error at all — mx check passed clean. Only the Mendix 11 copy exhibits this.

Workaround

None found that preserves the feature via mxcli. The call itself must be re-created in Studio Pro (open the affected decision/expression, re-select the same Rule from the picker, save) — a manual, GUI-only fix; mxcli cannot express this call in a way that survives a full microflow rewrite on Mendix 11.

Diagnostic bundle

Available: yes — mxcli-diag-20260820-153337.tar.gz (workspace root). As with the earlier reports, the bundle's own log only has abstract execute/success lines for the writes that actually caused the corruption (no error was raised at write time to log) — the CE0080/CE0117/"no callers found" evidence above was captured directly from mxcli docker check and mxcli callers output during the session.

Related

Possibly related to the general class of defect reported in #935 (ALTER PAGE silently corrupting a widget reference that round-trips as plausible-but-wrong MDL text) — both look like the writer producing a textually-plausible but semantically-empty reference for an element type it doesn't fully model (custom-content widgets there, Business Rule/Decision documents here).