Still reproduces verbatim on 0.21.0 — the fifth release running. Re-measured 2026-09-07 on a fresh mxcli new --version 11.11.0 app: check passes, exec exits 0 ("Created workflow"), DESCRIBE WORKFLOW round-trips, and mx.exe cannot load the project — no N errors. line at all.
Found 2026-06-10 probing workflow authoring on v0.12.0 AND nightly-20260609 against a fresh mxcli new --version 11.11.0 app.
Summary: decision … outcomes 'A' -> { } 'B' -> { }; inside CREATE WORKFLOW passes check, applies via exec ("Created workflow"), and DESCRIBE round-trips — but the outcome captions are stored as EnumerationValueIdentifiers. The .mpr then fails to LOAD in mx.exe / Studio Pro: Enumeration value condition outcome in workflow 'X' has an invalid value 'B' for property Value. The text 'B' is not a valid EnumerationValueIdentifier. (UnitLoader crash, full stacktrace). This is worse than a consistency error — the model is unopenable.
Root cause (apparent): the MDL grammar has no condition clause for decisions (mxcli syntax workflow decision shows none), so there's no enumeration/boolean/expression to bind outcomes to; mxcli stores raw caption text where a qualified enum-value reference belongs.
Recovery: mxcli -p <mpr> -c "DROP WORKFLOW Mod.Flow" still works on the corrupted unit (mxcli's own parser tolerates it) — model loads again after the drop.
Minimal repro:
create persistent entity Mod.R (Title: String(50));
create workflow Mod.F
parameter $R: Mod.R
begin
decision 'Check' outcomes 'A' -> { } 'B' -> { };
end workflow;
mxcli exec clean → mx check (11.11.0) → UnitLoader crash on load.
Probe verdict on the REST of the workflow grammar (same session): GREEN. Param + call microflow (parameter mappings auto-wired with (Request = '$WorkflowContext')) + user task (page/outcomes/nested activities) + parallel split → mx check 0 errors on 11.11.0. Two modeling requirements (not bugs): every user task needs a PAGE, and that page's param must be System.WorkflowUserTask (CE7412), not the context entity. Decision-outcome arrows are 'X' -> { } (the built-in syntax example omits the ->).
mxcli 0.21.0 (mxcli-windows-amd64.exe, 2026-09-06 build), Mendix 11.11.0 / 11.12.x, Windows 11. Each item was re-measured on a fresh app with a control of the same construct type, and every mx check verdict is the literal The app contains: N errors. line. We keep the full register with repros in our repo; happy to share more detail.
Still reproduces verbatim on 0.21.0 — the fifth release running. Re-measured 2026-09-07 on a fresh
mxcli new --version 11.11.0app:checkpasses,execexits 0 ("Created workflow"),DESCRIBE WORKFLOWround-trips, and mx.exe cannot load the project — noN errors.line at all.Found 2026-06-10 probing workflow authoring on v0.12.0 AND nightly-20260609 against a fresh
mxcli new --version 11.11.0app.Summary:
decision … outcomes 'A' -> { } 'B' -> { };insideCREATE WORKFLOWpassescheck, applies viaexec("Created workflow"), andDESCRIBEround-trips — but the outcome captions are stored as EnumerationValueIdentifiers. The.mprthen fails to LOAD in mx.exe / Studio Pro:Enumeration value condition outcome in workflow 'X' has an invalid value 'B' for property Value. The text 'B' is not a valid EnumerationValueIdentifier.(UnitLoader crash, full stacktrace). This is worse than a consistency error — the model is unopenable.Root cause (apparent): the MDL grammar has no condition clause for decisions (
mxcli syntax workflow decisionshows none), so there's no enumeration/boolean/expression to bind outcomes to; mxcli stores raw caption text where a qualified enum-value reference belongs.Recovery:
mxcli -p <mpr> -c "DROP WORKFLOW Mod.Flow"still works on the corrupted unit (mxcli's own parser tolerates it) — model loads again after the drop.Minimal repro:
mxcli execclean →mx check(11.11.0) → UnitLoader crash on load.Probe verdict on the REST of the workflow grammar (same session): GREEN. Param +
call microflow(parameter mappings auto-wiredwith (Request = '$WorkflowContext')) +user task(page/outcomes/nested activities) +parallel split→ mx check 0 errors on 11.11.0. Two modeling requirements (not bugs): every user task needs aPAGE, and that page's param must beSystem.WorkflowUserTask(CE7412), not the context entity. Decision-outcome arrows are'X' -> { }(the built-insyntaxexample omits the->).mxcli 0.21.0 (
mxcli-windows-amd64.exe, 2026-09-06 build), Mendix 11.11.0 / 11.12.x, Windows 11. Each item was re-measured on a fresh app with a control of the same construct type, and everymx checkverdict is the literalThe app contains: N errors.line. We keep the full register with repros in our repo; happy to share more detail.