Summary
mxcli describe entity and SELECT FROM CATALOG.ATTRIBUTES both report incorrect string-attribute lengths: a String attribute with a finite max length is reported as String(unlimited) (in MDL output) and Length: 0 (in the catalog), regardless of the actual length set on the attribute. The truth is only visible at runtime (rejection of overlong values) or in Studio Pro's attribute property panel.
This is a silent misreport — there is no warning, error, or log entry. The discrepancy only surfaces when a downstream consumer (a test that creates a fixture, an import script, an AI agent) writes a value longer than the actual limit and gets a runtime exception.
Environment
mxcli version: v0.11.0 (2026-05-21T18:04:46Z)- Platform:
go1.26.3 windows/amd64
- Mendix project version:
10.24.15.93102
- Diagnostic bundle:
mxcli-diag-20260522-161358.tar.gz (available — happy to share)
Steps to reproduce
In any Mendix project, take an entity with a String attribute that has a finite max length set in Studio Pro (e.g. String(40)):
mxcli -p <project>.mpr describe entity <Module>.<Entity>
Observed output (excerpt):
create or modify persistent entity <Module>.<Entity> (
...
Description: String(unlimited),
...
);
Cross-check via catalog:
mxcli -p <project>.mpr -c "SELECT Name, DataType, Length FROM CATALOG.ATTRIBUTES WHERE EntityQualifiedName = '<Module>.<Entity>'"
Observed output:
| Name | DataType | Length |
|-------------|----------|--------|
| Description | String | 0 |
In our case (Masterdata.Category.Description in a Mendix 10.24.15 project), Studio Pro shows the attribute as String(40), and the runtime rejects assignments of length 43 with:
Attribute 'Masterdata.Category.Description' has a maximum length of 40, tried setting a value of length 43.
Both mxcli describe entity and the catalog query consistently report unlimited / 0 for this same attribute. The entity inherits from AuditTrail.AudittrailSuperClass — possibly relevant, but the misreport also occurs without inheritance based on a quick check on other entities.
Expected behaviour
mxcli describe entity should emit the actual length (e.g. String(40)), and CATALOG.ATTRIBUTES.Length should hold the actual length value (e.g. 40). When the length truly is unlimited, both should still report unlimited / 0 — the bug is that every String attribute is reported as such.
Actual behaviour
All String attributes are reported with unlimited / Length: 0, regardless of the actual max-length configured in Studio Pro.
Impact
The bug is especially harmful for AI-agent workflows. The agent reads attribute metadata via mxcli describe entity or catalog queries, generates fixture data or import payloads accordingly, runs against the runtime, and gets a hard failure. There is no way for the agent to discover the true length without either inspecting the BSON directly (not supported via bson dump --type entity) or asking the human user to verify in Studio Pro.
This fits the broader pattern several earlier issues have flagged: mxcli silently misrepresents some BSON state. In this case it's a read-side bug (output is wrong) rather than a write-side one (state on disk is wrong).
Workaround
For now we cap fixture-value lengths conservatively (≤ 40 chars) for all String attributes on AudittrailSuperClass-derived entities, and we ask the human to confirm true lengths when it matters.
Notes
mxcli bson dump --type entity is not supported, so we cannot reach the raw BSON via mxcli to verify the actual length attribute on the model.- The MDL output appears to be the source of truth that
mxcli describe entity reads from, so a fix in one place might fix both surfaces (describe + catalog).
Summary
mxcli describe entityandSELECT FROM CATALOG.ATTRIBUTESboth report incorrect string-attribute lengths: aStringattribute with a finite max length is reported asString(unlimited)(in MDL output) andLength: 0(in the catalog), regardless of the actual length set on the attribute. The truth is only visible at runtime (rejection of overlong values) or in Studio Pro's attribute property panel.This is a silent misreport — there is no warning, error, or log entry. The discrepancy only surfaces when a downstream consumer (a test that creates a fixture, an import script, an AI agent) writes a value longer than the actual limit and gets a runtime exception.
Environment
mxcli version:v0.11.0 (2026-05-21T18:04:46Z)go1.26.3 windows/amd6410.24.15.93102mxcli-diag-20260522-161358.tar.gz(available — happy to share)Steps to reproduce
In any Mendix project, take an entity with a
Stringattribute that has a finite max length set in Studio Pro (e.g.String(40)):Observed output (excerpt):
Cross-check via catalog:
Observed output:
In our case (
Masterdata.Category.Descriptionin a Mendix 10.24.15 project), Studio Pro shows the attribute asString(40), and the runtime rejects assignments of length 43 with:Both
mxcli describe entityand the catalog query consistently reportunlimited/0for this same attribute. The entity inherits fromAuditTrail.AudittrailSuperClass— possibly relevant, but the misreport also occurs without inheritance based on a quick check on other entities.Expected behaviour
mxcli describe entityshould emit the actual length (e.g.String(40)), andCATALOG.ATTRIBUTES.Lengthshould hold the actual length value (e.g.40). When the length truly is unlimited, both should still reportunlimited/0— the bug is that everyStringattribute is reported as such.Actual behaviour
All
Stringattributes are reported withunlimited/Length: 0, regardless of the actual max-length configured in Studio Pro.Impact
The bug is especially harmful for AI-agent workflows. The agent reads attribute metadata via
mxcli describe entityor catalog queries, generates fixture data or import payloads accordingly, runs against the runtime, and gets a hard failure. There is no way for the agent to discover the true length without either inspecting the BSON directly (not supported viabson dump --type entity) or asking the human user to verify in Studio Pro.This fits the broader pattern several earlier issues have flagged: mxcli silently misrepresents some BSON state. In this case it's a read-side bug (output is wrong) rather than a write-side one (state on disk is wrong).
Workaround
For now we cap fixture-value lengths conservatively (≤ 40 chars) for all String attributes on AudittrailSuperClass-derived entities, and we ask the human to confirm true lengths when it matters.
Notes
mxcli bson dump --type entityis not supported, so we cannot reach the raw BSON via mxcli to verify the actual length attribute on the model.mxcli describe entityreads from, so a fix in one place might fix both surfaces (describe + catalog).