`check --references` passes on a loop-variable association path inlined as a call-microflow parameter; native mxbuild then fails with CE0117

[MendixMau]

Environment

• mxcli v0.17.0 (2026-08-10T05:12:17Z). Originally observed on an unrecorded 2026-08-13/14 build — see Severity note.
• Retested on mxcli v0.18.0 (2026-08-14T20:29:13Z, official darwin-arm64 release binary): still reproduces, unchanged.
• Mendix Studio Pro / mxbuild 11.13.0
• macOS 26.6, arm64

Summary

A call microflow activity whose parameter value directly inlines a loop variable's
association-path member access ($Item/"Attr") passes both mxcli check --references and
mxcli exec with 0 errors, but the resulting model fails native mx check with CE0117 "Error(s) in expression." at that exact activity, and mxcli docker build fails outright.

mxcli's own validation never catches it. The first signal is the native build.

Steps to reproduce

Given an entity Mod.Item with a StatusCode : String(10) attribute, and a microflow
Mod.SUB_EvaluateAvailability taking one StatusCode : String parameter:

loop $Item in $Items
begin
  $IsOnline = call microflow "Mod"."SUB_EvaluateAvailability" (
    "StatusCode" = $Item/"StatusCode"
  );
end loop;

mxcli check --references script.mdl -p Project.mpr   → 0 errors
mxcli exec script.mdl -p Project.mpr                 → success
mx check Project.mpr                                 → [error] [CE0117] "Error(s) in expression."
mxcli docker build -p Project.mpr                    → fails

Expected

Either the construct compiles, or mxcli check --references rejects it before exec writes it
to the model.

Actual

Both mxcli static checks pass; native mxbuild rejects the activity; the build fails.

Isolation already performed

• Not a stale-model artifact. The exact MDL for the affected microflow was taken byte-for-byte
  from DESCRIBE MICROFLOW output and re-executed against a freshly reset .mpr. It failed
  native mx check with the identical CE0117 at the identical activity. The defect is in how
  mxcli represents this parameter-mapping shape, not in accumulated model history.
• Not a genuine type mismatch. Confirmed via CATALOG.ATTRIBUTES that both sides line up:
  $Item/StatusCode is String(10), the callee's $StatusCode parameter is String.

Trigger boundary

Form	mxcli check	mx check
"StatusCode" = $Item/"StatusCode" (inlined association path from loop var)	0 errors	CE0117
declare $ItemStatusCode string = $Item/"StatusCode"; then "StatusCode" = $ItemStatusCode	0 errors	0 errors, build succeeds

The two forms are semantically identical. Only the inlined one fails.

Workaround

Bind the association-path expression to an intermediate declared variable, then pass the
variable:

loop $Item in $Items
begin
  declare $ItemStatusCode string = $Item/"StatusCode";
  $IsOnline = call microflow "Mod"."SUB_EvaluateAvailability" (
    "StatusCode" = $ItemStatusCode
  );
end loop;

Verified: mxcli docker build succeeds with 0 errors in this form, where the byte-identical
inlined form failed every time.

Severity

Build-breaker, not silent. The model is written and only the native toolchain rejects it, so a
project can accumulate several of these before anyone runs mx check.

Scoped to mxbuild 11.13.0. Not tested on 11.12.x. The
severity claim covers only the environment above.

Suggested fix location

Either the expression-codegen path that emits the parameter mapping for a call activity (so the
inlined form emits what the declare form emits), or check --references, so the construct is
rejected before exec writes it.