Solution exists in fork: engalar/mxcli fixed this in commit dd62aaf81 (2026-05-26,
"fix(describe): use gen modelsdk for MicroflowSource/NanoflowSource datasource extraction").
Verified by direct BSON inspection (2026-08-05): re-ran the repro below against RnD
v0.16.0, then read the resulting .mxunit BSON directly (bypassing describe entirely).
The datagrid's Forms$MicroflowSource property is written correctly —
DataSource.MicroflowSettings.Microflow = "ZZB.DS_Routes" is present and correct in the
stored BSON. mxcli describe page ZZB.P_R10c on that same file omits the datasource from
dgRoutes entirely. The write path is not broken; only describe's read-back is. This
confirms the fork commit's own diagnosis and narrows the fix to the read-back layer only.
Environment: mxcli (RnD/upstream), Mendix 11.12.0 project.
Steps to reproduce:
create module ZZB;
/
create persistent entity ZZB."Routing" (
"RoutingCode": String(100),
"RoutingName": String(200)
);
/
create microflow ZZB."DS_Routes" ()
returns List of ZZB."Routing" as $Routes
begin
retrieve $Routes from ZZB."Routing";
return $Routes;
end;
/
create page ZZB."P_R10c" (
Title: 'R10c',
Layout: Atlas_Core.Atlas_TopBar
)
{
datagrid dgRoutes (DataSource: microflow ZZB."DS_Routes") {
column RoutingCode (Attribute: RoutingCode, Caption: 'Routing Code')
}
}
Run mxcli exec script.mdl -p project.mpr, then mxcli describe page ZZB.P_R10c (or the
equivalent DESCRIBE PAGE command).
Expected behavior: DESCRIBE PAGE read-back should show dgRoutes bound to the
ZZB.DS_Routes microflow datasource, matching what was written.
Actual behavior: mx check passes clean (0 errors) — a datagrid with no datasource
recorded would still be structurally valid to Studio Pro, so validation couldn't catch this
either way. DESCRIBE PAGE shows dgRoutes with no datasource at all — but this is a
reporting gap, not the true state: the datasource is correctly stored in the .mpr, as
confirmed by direct BSON inspection (see below).
Root cause (confirmed by BSON inspection, matches the fork's own diagnosis):
extractDataGrid2DataSource (the function DESCRIBE uses to report a datagrid's datasource)
reads the microflow name from ds["Microflow"] directly, which is always nil/empty for this
datasource type — the real BSON path is ds["MicroflowSettings"]["Microflow"]. Decoding the
page unit's raw BSON directly shows the widget's Forms$MicroflowSource property with
MicroflowSettings.Microflow correctly set to "ZZB.DS_Routes" — the write path stores it
correctly. describe simply looks in the wrong field when reading it back. The same bug
exists in the Gallery datasource extractor. The fork's fix added typed decoder helpers
(decodeMicroflowQNFromSource, decodeNanoflowQNFromSource) plus a pre-commit hook banning
raw string-literal BSON field access in the describe pipeline going forward.
Severity note: because this is read-back only, it does not cause data loss or corrupt the
built app — a datagrid built this way runs correctly in Studio Pro/at runtime despite what
describe shows. The impact is confined to mxcli describe/tooling built on top of it giving
a false "no datasource" signal, which is still worth fixing (it can mislead anyone diffing or
auditing a project via describe) but is lower severity than initially suspected.
Environment: mxcli (RnD/upstream), Mendix 11.12.0 project.
Steps to reproduce:
Run
mxcli exec script.mdl -p project.mpr, thenmxcli describe page ZZB.P_R10c(or theequivalent
DESCRIBE PAGEcommand).Expected behavior:
DESCRIBE PAGEread-back should showdgRoutesbound to theZZB.DS_Routesmicroflow datasource, matching what was written.Actual behavior:
mx checkpasses clean (0 errors) — a datagrid with no datasourcerecorded would still be structurally valid to Studio Pro, so validation couldn't catch this
either way.
DESCRIBE PAGEshowsdgRouteswith no datasource at all — but this is areporting gap, not the true state: the datasource is correctly stored in the
.mpr, asconfirmed by direct BSON inspection (see below).
Root cause (confirmed by BSON inspection, matches the fork's own diagnosis):
extractDataGrid2DataSource(the functionDESCRIBEuses to report a datagrid's datasource)reads the microflow name from
ds["Microflow"]directly, which is alwaysnil/empty for thisdatasource type — the real BSON path is
ds["MicroflowSettings"]["Microflow"]. Decoding thepage unit's raw BSON directly shows the widget's
Forms$MicroflowSourceproperty withMicroflowSettings.Microflowcorrectly set to"ZZB.DS_Routes"— the write path stores itcorrectly.
describesimply looks in the wrong field when reading it back. The same bugexists in the Gallery datasource extractor. The fork's fix added typed decoder helpers
(
decodeMicroflowQNFromSource,decodeNanoflowQNFromSource) plus a pre-commit hook banningraw string-literal BSON field access in the describe pipeline going forward.
Severity note: because this is read-back only, it does not cause data loss or corrupt the
built app — a datagrid built this way runs correctly in Studio Pro/at runtime despite what
describeshows. The impact is confined tomxcli describe/tooling built on top of it givinga false "no datasource" signal, which is still worth fixing (it can mislead anyone diffing or
auditing a project via
describe) but is lower severity than initially suspected.