`DESCRIBE MICROFLOW` omits `without events`, so a DESCRIBE → exec round-trip silently turns commit event handlers back on

[MendixMau]

Summary

mxcli's bare commit $X; now defaults to WITH EVENTS, matching Studio Pro. It previously
meant events OFF. That change is defensible on its own — the defect is that DESCRIBE MICROFLOW prints a bare commit $X; for both settings. The events flag is not round-tripped.

So the standard repoint workflow — DESCRIBE a microflow, change one activity, re-exec it —
silently flips the commit semantics of every commit in the flow that had events off.

Environment

• mxcli v0.20.0
• Mendix 11.13.0
• Linux container

Why nothing catches it

• mxcli check --references passes.
• mxbuild / mx check pass — the model is structurally valid.
• The behaviour change appears only at run time, in whatever the event handlers do.

On the project where this was found it happened to be inert (no entity in any of seven modules
declares an event handler, checked) — which is exactly why it would have shipped unnoticed on a
project where one does. The only reason it surfaced at all is that mxcli's own MDL067 info
message fired on a large enough re-emitted flow.

Expected

DESCRIBE emits commit $X without events; whenever the stored activity has events off. A
round-trip must not change behaviour.

Failing that, MDL067 should fire on every bare commit in a script that also contains a
create or modify microflow, rather than on a heuristic that a smaller flow slips past.

Related

BUG-103 (DESCRIBE MICROFLOW emits log strings with embedded doubled quotes that mxcli check
then rejects). Same class: DESCRIBE output that is not a faithful, re-executable representation
of the model.

[ako]

Thanks for the detailed report — the underlying defect was real, and your
"Expected Behavior" is exactly what's implemented today. I could not reproduce
it on 0.21.0 or on current main, so I think this is fixed in a build later
than the one you tested.

What I measured

Mendix 11.12.1, MPR v2, on current main and on a binary built from the
v0.21.0 release commit — both give the same results:

stored activity	DESCRIBE MICROFLOW emits
commit $o without events;	commit $o without events;
commit $o; (control)	commit $o;
same, MXCLI_ENGINE=legacy	commit $o without events;
create … commit without events	preserved
change $In (…) commit without events	preserved
commit inside a LOOP	preserved

The full round trip holds too: describe → exec → describe keeps the flag,
and the write is elided (Unchanged microflow: …), meaning the rebuilt
document was semantically identical to the stored one rather than merely
looking similar.

The related BUG-103 claim also doesn't reproduce: LOG 'it''s here' describes
as log info node 'Application' 'it''s here';, and that output passes
mxcli check.

Why

This was fixed as part of #895, which is the same failure you describe — a
commit with events off coming back with them on after a round trip. The
describer now spells out the deviation, with the reasoning in the code at
mdl/executor/cmd_microflows_format_action.go, and there's a regression
fixture at mdl-examples/bug-tests/895-commit-events-and-refresh-defaults.mdl.
Your report is against v0.20.0; the 0.20.0 release notes mention only the
lint side of this (MDL067), not the describe side.

If you're actually on 0.21.0 or later

Then your project has a shape none of the six variants above covers, and I'd
rather not guess at it. The most useful things would be:

• the exact mxcli --version, and
• for one affected activity, the describe microflow <name> output alongside
  the stored Microflows$CommitAction node from the .mxunit — its
  WithEvents value specifically.

One difference worth naming: I tested on Mendix 11.12.1 and you're on
11.13.0. I don't have a reason to think that matters here — the property is
version-stable and the key is WithEvents on both — but I haven't ruled it out,
and a stored activity from your project would settle it either way.