Skip to content

DESCRIBE PAGE doesn't report a DataGrid2's microflow datasource — read-back bug, not data loss #839

Description

@MendixMau

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions