Issue with loops in Microflows

[jwinckelmann]

I made some tests with Microflows and noticed that the MDL representations of loops are not complete, the actual Actions within the loop are not there. The project I used is based on Studio Pro v11.6.1, mxcli is v0.3.0.

          @position(4006, 498)
          @annotation 'xxx'
          LOOP $IteratorUniqueUserIdentity IN $UniqueUserIdentityList

          @position(4470, 498)
          @annotation 'xxx'
          LOOP $IteratorREST_MendixUser IN $REST_MendixUserList_merged

[github-actions]

Issue Triage

Summary:
The user reports that when mxcli processes a Mendix project (Studio Pro v11.6.1, mxcli v0.3.0), the generated MDL for loops in microflows omits the actions inside the loops.

Checklist of required bug‑report information

Required info	Present?	Notes
mxcli version	✅	v0.3.0 given
Mendix version	✅	Studio Pro v11.6.1 given
Scenario (what the user was trying to do)	⚠️	Mentioned testing Microflows and seeing incomplete MDL; could be clarified (e.g., which mxcli command was run)
Expected output	❌	Not stated what the MDL should contain
Experienced output	❌	Shown MDL snippet but no explicit description of the missing actions or any error messages
AI bug report (mxcli diag --bundle or session log)	❌	Not provided

What’s missing & polite request

To help us investigate, could you please add the following details?

1. Expected output: What should the MDL look like for a loop (e.g., the actions that should appear inside the LOOP … ENDLOOP block)?
2. Experienced output: A clearer description of what is missing or any error/warning messages you saw when running mxcli.
3. The exact mxcli command you used (e.g., mxcli read … or mxcli modify …) so we can reproduce the scenario.
4. Diagnostic bundle: Run mxcli diag --bundle and attach the resulting zip, or at least share the relevant session log.

Once we have that information, we’ll be able to pinpoint why the loop actions aren’t being emitted and work on a fix. Thanks for bringing this to our attention!

---

Automated triage via OpenRouter — workflow source

[ako]

Might be a duplicate of #39

[ako]

Investigation

This is a duplicate of #39. The fix was implemented in commit 6764cda (2026-03-26) but is not included in v0.3.0 — the version you're using.

What was fixed

The DESCRIBE MICROFLOW loop body traversal (emitLoopBody / traverseLoopBody in cmd_microflows_show_helpers.go) works by following the flow graph through loop body activities. There was a bug in the WHILE loop path (missing END WHILE traversal), fixed in 6764cda. The FOR EACH loop path was already working but depended on the same code path.

A roundtrip test (TestRoundtripMicroflow_LoopWithBody) confirms loop body activities are correctly emitted on the current main branch.

Resolution

Update to the latest mxcli build from main (post-v0.3.0). The fix will be included in the next release.

# Build from source
go install github.com/mendixlabs/mxcli/cmd/mxcli@latest

If you still see empty loop bodies after updating, please share a minimal reproduction project so we can investigate further.

[ako]

Can you retest with v0.4.0?

[rbolt]

Retested with MSP 11.6.2 and MxCli 0.4.0.
Result: activities are not shown in the output if loop is placed after a decision AND the 'END LOOP;' is missing.

Microflow:

MxCLI output;
CREATE OR REPLACE MICROFLOW TestExamplesModule.ACT_loop_after_if ()
RETURNS String
FOLDER 'Input'
BEGIN
@position(288, 200)
IF true THEN
@position(462, 200)
RETRIEVE $Companys FROM TestExamplesModule.Company
WHERE Name != empty
SORT BY TestExamplesModule.Company.Name ASC
LIMIT 20
OFFSET 10;
@position(646, 200)
LOOP $Company IN $Companys
@position(798, 200)
RETURN $'MicrolfowResult';
ELSE
@position(288, 314)
RETURN empty;
END IF;
END;
/

[jwinckelmann]

Thanks, @ako for taking care. IMHO this tool can change everything for Mendix development.

I checked again with 0.4.0 and the result is still the same for me.

     @position(4006, 498)
      LOOP $IteratorUniqueUserIdentity IN $UniqueUserIdentityList
      @position(4470, 498)
      LOOP $IteratorREST_MendixUser IN $REST_MendixUserList_merged

I removed the annotations here now.

These are the logs:

"time":"2026-04-01T11:58:52.1894974+02:00","level":"INFO","msg":"session_start","version":"v0.4.0","go":"go1.26.1","os":"windows","arch":"amd64","mode":"batch","args":["C:\\DEVTOOLS\\Mendix\\mxcli\\mxcli.exe","-p","Mendix User Manager.mpr","-c","DESCRIBE MICROFLOW MendixUserManagerModule.SUB_CreateOrMapUniqueIdentity"],"pid":27364}
{"time":"2026-04-01T11:58:52.2027317+02:00","level":"INFO","msg":"connect","mpr_path":"Mendix User Manager.mpr","mendix_version":"11.6.1","mpr_format":2}
{"time":"2026-04-01T11:58:52.2027317+02:00","level":"INFO","msg":"execute","stmt_type":"ConnectStmt","stmt_summary":"CONNECT LOCAL 'Mendix User Manager.mpr'","duration_ms":1}
{"time":"2026-04-01T11:58:53.092518+02:00","level":"INFO","msg":"execute","stmt_type":"DescribeStmt","stmt_summary":"DESCRIBE MICROFLOW MendixUserManagerModule.SUB_CreateOrMapUniqueIdentity","duration_ms":889}
{"time":"2026-04-01T11:58:53.092518+02:00","level":"INFO","msg":"session_end","commands_executed":2,"errors_count":0,"duration_s":0}

[ako]

Root Cause Found & Fixed

Thanks @rbolt for the clear reproduction — loop after a decision was the key clue.

The bug

traverseFlowUntilMerge() (which handles activities inside IF/ELSE branches) had no special handling for LoopedActivity. When a loop appeared inside a branch, it fell through to the "regular activity" path which:

• Emitted the LOOP header line
• But never called emitLoopBody() to process activities inside the loop
• And never appended END LOOP;

The top-level traverseFlow() and traverseLoopBody() both had the correct LoopedActivity handling — it was only missing in the branch traversal path.

The fix

Added explicit LoopedActivity handling in traverseFlowUntilMerge, matching the existing pattern in the other two traversal functions. Also added regression test TestRoundtripMicroflow_LoopInsideBranch.

Fix: 42e1c40

@jwinckelmann your case (two consecutive loops without a decision) may be a different issue — could you try again once this fix is released? If the loops in your microflow happen to be after a decision somewhere in the flow, this fix should resolve it.

[jwinckelmann]

In my case there are several decisions before the loop, they are located quite at the end. So hopefully this is covered by fix too.