CE7033 (`IN QUEUE` on a non-Nothing microflow) is an untreated sibling of the CE1571 datasource-argument check

[marclehane-creator]

Scope note (2026-09-07): mxcli 0.21.0's new MDL073 now catches the CE0142 half of this (After-startup microflow return type). This issue is the remaining CE7033 half only — IN QUEUE on a microflow whose return type is not Nothing still passes check --references.

0.20.0 rightly closes "a microflow data source with no arguments" by comparing a microflow's
signature against the arguments at its binding site — machinery that clearly exists now. The same
shape (both halves are in the model and nothing compares them) is still open in two places:

written	mxcli check -p --references	mx check
CALL MICROFLOW M.F(…) IN QUEUE M.Q where F returns Boolean	Check passed!	CE7033 "A microflow used for background execution must have a Microflow return type of 'Nothing'."
ALTER SETTINGS MODEL AfterStartupMicroflow = M.F where F returns nothing	Check passed!	CE0142 "After startup microflow should return a boolean."

Both were measured with the referenced flow already existing in the project (so no reference error
could short-circuit the run). Each is a single return-type comparison at a binding mxcli itself
wrote moments earlier.

⚠ The second one is adjacent to a fix this release shipped: 0.20.0 now refuses
AfterStartupMicroflow = empty (Issue 39, closed — see below), so that statement already resolves
and inspects the named microflow. Checking its return type is the next step in the same code path.

---

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.