Summary
declare $list list of Module.Entity = empty; parses and passes mxcli check, but Studio Pro's mx check rejects it with CE0053 ("type not allowed") and CE0038 ("value required"). In Mendix, declare maps to a Create Variable activity, which is not allowed for list data types (empty lists must use a Create List activity). So mxcli green-lights logic that crashes the project on open / mx check.
This is the concrete instance behind the broader "mxcli check vs mx check divergence" feedback.
Reproduction
create microflow MyFirstModule.TestEmptyList()
begin
declare $Items list of MyFirstModule.Cars = empty;
end
$ ./bin/mxcli check /tmp/t.mdl
✓ Syntax OK (1 statements)
Check passed!
…then opening the project in Studio Pro → CE0053 + CE0038.
Why it slips through today
- Lint rule MDL002 only flags an empty-list variable when it is used as a LOOP source (
mdl/executor/validate_microflow.go ~line 139), not the declare … = empty itself.
- The skills/docs present it as valid syntax with no warning:
.claude/skills/mendix/write-microflows.md:137
.claude/skills/mendix/check-syntax.md:21
.claude/skills/mendix/patterns-data-processing.md:217,261,300
CLAUDE.md:469 even claims violations are "caught by mxcli check" (aspirational).
Proposed fix (options)
- Validation:
mxcli check should error (or warn) on list-typed declare … = empty, pointing users to: pass the list as a microflow parameter, populate it immediately with retrieve, or use a Create List construct.
- Or make it valid: emit a Create List activity for list-typed
declare, so the output is accepted by Studio Pro.
- Docs: update the skills/CLAUDE.md so the accumulation pattern shown is actually Studio-Pro-valid.
Reported via external user feedback (AI-agent MDL generation).
Summary
declare $list list of Module.Entity = empty;parses and passesmxcli check, but Studio Pro'smx checkrejects it with CE0053 ("type not allowed") and CE0038 ("value required"). In Mendix,declaremaps to a Create Variable activity, which is not allowed for list data types (empty lists must use a Create List activity). So mxcli green-lights logic that crashes the project on open /mx check.This is the concrete instance behind the broader "
mxcli checkvsmx checkdivergence" feedback.Reproduction
…then opening the project in Studio Pro → CE0053 + CE0038.
Why it slips through today
mdl/executor/validate_microflow.go~line 139), not thedeclare … = emptyitself..claude/skills/mendix/write-microflows.md:137.claude/skills/mendix/check-syntax.md:21.claude/skills/mendix/patterns-data-processing.md:217,261,300CLAUDE.md:469even claims violations are "caught bymxcli check" (aspirational).Proposed fix (options)
mxcli checkshould error (or warn) on list-typeddeclare … = empty, pointing users to: pass the list as a microflow parameter, populate it immediately withretrieve, or use a Create List construct.declare, so the output is accepted by Studio Pro.Reported via external user feedback (AI-agent MDL generation).