Solution exists (unmerged): a patch authored by engalar/mxcli's own author
(liuwengao@foxmail.com, dated 2026-07-30) fixes this. It's a packaged handoff — repro
project, MDL scripts, before/after BSON evidence, and verification tools included — not a
loose diff. It was independently re-verified in this audit: applied cleanly to a scratch
clone, rebuilt, and confirmed the root occurrence flips from 0..0 to 1..1 with no
regression on the related array-JsonPath bug. The patch is not on dev or any other
fetched branch of the fork — it exists only as a standalone file today. Happy to share it on
request; contains no project-specific or confidential content, just a generic MDL repro.
Environment: mxcli (RnD/upstream, v0.16.0), Mendix 11.12.0/11.12.1 project.
Steps to reproduce:
create module ZZB;
/
create json structure ZZB."JSON_SearchRoutes"
snippet $${"pagination":{"page":1,"pageSize":1,"totalItems":10,"totalPages":10},"items":[{"routing_id":"8ac9a044-65ae-43f6-b838-a05fb4dd8e9e","routing_code":"RT-PCBA-001","routing_name":"Routing for PCBA line 1","row_version":1}]}$$;
Run mxcli exec script.mdl -p project.mpr, then inspect the written .mxunit BSON for the
structure's root element occurrence (minOccurs/maxOccurs), or bind an import mapping to it
and run the mapping against a matching payload.
Expected behavior: The root element of a JSON structure generated from a snippet should
have occurrence 1..1 (it always occurs exactly once), matching Studio Pro's own generator.
Optional elements should get 0..1, array items 0..*.
Actual behavior: Every element's occurrence is written as 0..0, including the root. mx check passes clean (0 errors) — occurrence 0..0 is not itself a schema error to Studio Pro's
validator, so this is a silent semantic bug, not a compile error. Since Mendix never
instantiates an element that "may occur zero times," any import mapping bound to this
structure silently produces zero objects at runtime: the REST call returns 200, the page
renders empty rows, and mxcli check, --references, mxbuild, and Studio Pro's error pane
all report clean. There is no signal anywhere that anything is wrong short of noticing the
data never arrives.
Root cause / fix (per the unmerged patch): the structure generator has a stale assumption
that "0 = default (1)" for occurrence — Mendix does not read it that way. The patch changes
generation so root elements are written 1..1, optional elements 0..1, and array items
0..*, matching Studio Pro's own generator (verified against 11.12.1). Both the import and
export mapping code paths needed the same fix, since mxbuild compares a mapping's stored
occurrence against the structure's literally and raises CE5015 on mismatch otherwise.
Given the silent-data-loss severity (a working-looking integration that quietly imports
nothing) and that a verified fix already exists and is offered to be shared, this seems like a
good candidate for fast-tracking regardless of which fork ships it first.
Environment: mxcli (RnD/upstream, v0.16.0), Mendix 11.12.0/11.12.1 project.
Steps to reproduce:
Run
mxcli exec script.mdl -p project.mpr, then inspect the written.mxunitBSON for thestructure's root element occurrence (
minOccurs/maxOccurs), or bind an import mapping to itand run the mapping against a matching payload.
Expected behavior: The root element of a JSON structure generated from a snippet should
have occurrence
1..1(it always occurs exactly once), matching Studio Pro's own generator.Optional elements should get
0..1, array items0..*.Actual behavior: Every element's occurrence is written as
0..0, including the root.mx checkpasses clean (0 errors) — occurrence0..0is not itself a schema error to Studio Pro'svalidator, so this is a silent semantic bug, not a compile error. Since Mendix never
instantiates an element that "may occur zero times," any import mapping bound to this
structure silently produces zero objects at runtime: the REST call returns 200, the page
renders empty rows, and
mxcli check,--references,mxbuild, and Studio Pro's error paneall report clean. There is no signal anywhere that anything is wrong short of noticing the
data never arrives.
Root cause / fix (per the unmerged patch): the structure generator has a stale assumption
that "0 = default (1)" for occurrence — Mendix does not read it that way. The patch changes
generation so root elements are written
1..1, optional elements0..1, and array items0..*, matching Studio Pro's own generator (verified against 11.12.1). Both the import andexport mapping code paths needed the same fix, since
mxbuildcompares a mapping's storedoccurrence against the structure's literally and raises
CE5015on mismatch otherwise.Given the silent-data-loss severity (a working-looking integration that quietly imports
nothing) and that a verified fix already exists and is offered to be shared, this seems like a
good candidate for fast-tracking regardless of which fork ships it first.