Summary
DESCRIBE MICROFLOW correctly emits Mendix inline if...then...else expressions (used in SET assignments), but mxcli exec fails to parse them back. This makes the DESCRIBE → exec roundtrip impossible for any microflow containing a conditional expression assignment.
Steps to Reproduce
Using a microflow that contains a SET action with an inline conditional expression (e.g. ConversationalUI.DS_TokenMonitor_UsageList):
# 1. Capture DESCRIBE output
mxcli -p app.mpr -c "DESCRIBE MICROFLOW ConversationalUI.DS_TokenMonitor_UsageList;" > a.mdl
# 2. Drop the original
mxcli -p app.mpr -c "DROP MICROFLOW ConversationalUI.DS_TokenMonitor_UsageList;"
# 3. Re-create — this fails
mxcli exec a.mdl -p app.mpr
DESCRIBE Output (a.mdl) — the problematic fragment
SET $EndOfCurrentBin = if $EndOfCurrentBin > $TokenMonitorSettings/DateTo then
$TokenMonitorSettings/DateTo
else
$EndOfCurrentBin;
This is valid Mendix expression syntax (lowercase if...then...else), but mxcli exec rejects it.
Actual Error
Parse error: line 31:49 no viable alternative at input '$EndOfCurrentBin>'
Parse error: line 31:80 extraneous input 'then' expecting {<EOF>, CREATE, ALTER, DROP, ...}
Parse error: line 33:0 extraneous input 'else' expecting {<EOF>, CREATE, ALTER, DROP, ...}
The parser interprets the if keyword as starting a top-level IF...THEN...END IF block, then fails when it encounters the expression $EndOfCurrentBin > ... instead of a condition.
Expected Behavior
mxcli exec should parse and write the inline if...then...else Mendix expression correctly:
-- Mendix expression syntax: lowercase if, inline, terminates at ;
SET $Var = if <condition> then <expr1> else <expr2>;
Root Cause
The MDL grammar treats if as a statement-level keyword (→ IF...THEN...END IF block) and does not handle the Mendix expression-level if...then...else construct inside expression positions (RHS of SET, CHANGE attribute values, DECLARE default values, etc.).
Environment
- Mendix version: 11.6.4
- Affected module:
ConversationalUI (Marketplace v3.0.0) — any microflow with a conditional expression in a SET action
Impact
High. Mendix uses inline if...then...else widely in generated and hand-written microflows. Any such microflow produces a DESCRIBE output that cannot be re-executed, fully breaking the roundtrip. The dropped microflow is also not restored, leaving references dangling (CE1613).
Summary
DESCRIBE MICROFLOWcorrectly emits Mendix inlineif...then...elseexpressions (used in SET assignments), butmxcli execfails to parse them back. This makes the DESCRIBE → exec roundtrip impossible for any microflow containing a conditional expression assignment.Steps to Reproduce
Using a microflow that contains a SET action with an inline conditional expression (e.g.
ConversationalUI.DS_TokenMonitor_UsageList):DESCRIBE Output (a.mdl) — the problematic fragment
This is valid Mendix expression syntax (lowercase
if...then...else), butmxcli execrejects it.Actual Error
The parser interprets the
ifkeyword as starting a top-levelIF...THEN...END IFblock, then fails when it encounters the expression$EndOfCurrentBin > ...instead of a condition.Expected Behavior
mxcli execshould parse and write the inlineif...then...elseMendix expression correctly:Root Cause
The MDL grammar treats
ifas a statement-level keyword (→IF...THEN...END IFblock) and does not handle the Mendix expression-levelif...then...elseconstruct inside expression positions (RHS of SET, CHANGE attribute values, DECLARE default values, etc.).Environment
ConversationalUI(Marketplace v3.0.0) — any microflow with a conditional expression in a SET actionImpact
High. Mendix uses inline
if...then...elsewidely in generated and hand-written microflows. Any such microflow produces aDESCRIBEoutput that cannot be re-executed, fully breaking the roundtrip. The dropped microflow is also not restored, leaving references dangling (CE1613).