XPath constraint containing a [%…%] token (e.g. [%CurrentUser%]) fails CE0161 after apply

[marclehane-creator]

mxcli version: v0.11.0 (2026-05-21) · OS: Windows 11 · Mendix project: runtime 11.10.0

Summary

Any retrieve/datasource XPath constraint that contains a Mendix system token such as [%CurrentUser%] produces CE0161 "Error(s) in XPath constraint." after the script is applied (verified with Mendix's own mx check). Constraints without a [%…%] token are fine, so the most common real query — "records owned by the current user" — cannot be authored via mxcli.

Minimal repro

Apply this with mxcli exec -p <App.mpr> repro.mdl, then run mx check against the .mpr:

create or modify persistent entity Administration.MxfBase (Title: String(100));
create or modify microflow Administration.Mf_Base ()
begin
  retrieve $L from Administration.MxfBase where [Title='abc'];
  return;
end;

create or modify persistent entity Administration.MxfTok (Title: String(100));
create or modify microflow Administration.Mf_Tok ()
begin
  retrieve $L from Administration.MxfTok where [Title='[%CurrentUser%]'];
  return;
end;

Expected

Both retrieves pass mx check. [%CurrentUser%] is a valid Mendix XPath token.

Actual

• Mf_Base → clean.
• Mf_Tok → CE0161 "Error(s) in XPath constraint." at Retrieve … MxfTok.

The same failure occurs for [System.owner='[%CurrentUser%]'] and for the single-quoted ('[Title=''[%CurrentUser%]'']') and double-quoted ("[Title='[%CurrentUser%]']") forms. mxcli exec itself reports no error — only the applied model fails mx check.

Likely cause

The where-clause parser appears to treat the inner [ / ] of the [%token%] as constraint-bracket delimiters (nested-bracket mishandling), so the stored XPath is truncated/corrupted. Isolated cleanly: [Title='abc'] = OK; the only change that flips it to FAIL is adding a [%…%] token, independent of the compared member.

Impact

Blocks every owner-/user-/session-token-filtered retrieve or datasource — a near-universal Mendix pattern ([System.owner='[%CurrentUser%]'], [%CurrentUser%], [%CurrentDateTime%], etc.).

[github-actions]

Issue Triage

Summary:
The user reports that mxcli v0.11.0 corrupts XPath constraints containing Mendix system tokens (e.g., [%CurrentUser%]), causing mx check to fail with error CE0161 after applying an MDL script.

Checklist (bug report)

Required info	Present?	Details
mxcli version	✅	v0.11.0 (2026-05-21)
Mendix version	✅	runtime 11.10.0
Scenario (what was tried)	✅	mxcli exec -p <App.mpr> repro.mdl then mx check
Expected output	✅	Both retrieves should pass mx check
Experienced output	✅	Mf_Tok yields CE0161 "Error(s) in XPath constraint."
AI bug report (mxcli diag --bundle or session log)	❌	Not included

Missing information:
Could you please provide the output of mxcli diag --bundle (or at least the relevant session log) so we can investigate the exact state of the tool when the issue occurs? This will help us pinpoint where the XPath token handling goes wrong.

Thank you for reporting the issue! Once we have the diagnostic bundle, we’ll be able to look into the fix.

---

Automated triage via OpenRouter — workflow source

[marclehane-creator]

Diagnostic info as requested (re-confirmed today on a fresh Mendix 11.10 project).

Environment

• mxcli v0.11.0 (2026-05-21), MPR format 2, Windows/amd64
• Mendix runtime 11.10.0; consistency checked with mx.exe check (11.10.0 modeler)

Repro (mxcli exec this, then mx check):

create or modify persistent entity Administration.MxfBase (Title: String(100));
create or modify microflow Administration.Mf_Base ()
begin
  retrieve $L from Administration.MxfBase where [Title='abc'];
  return;
end;
create or modify persistent entity Administration.MxfTok (Title: String(100));
create or modify microflow Administration.Mf_Tok ()
begin
  retrieve $L from Administration.MxfTok where [Title='[%CurrentUser%]'];
  return;
end;

mxcli session log (mxcli diag --tail) — exec applies with no error:

{"level":"INFO","msg":"execute","stmt_type":"CreateMicroflowStmt","stmt_summary":"create microflow Administration.Mf_Base","duration_ms":1296}
{"level":"INFO","msg":"execute","stmt_type":"CreateMicroflowStmt","stmt_summary":"create microflow Administration.Mf_Tok","duration_ms":225}
{"level":"INFO","msg":"session_end","commands_executed":5,"errors_count":0,"duration_s":2}

mx check output — only the [%CurrentUser%] retrieve fails:

[error] [CE0161] "Error(s) in XPath constraint." at Retrieve object(s) activity 'Retrieve list of MxfTok from database'
The app contains: 1 errors.

Mf_Base (plain [Title='abc']) is clean; Mf_Tok (identical but with the [%CurrentUser%] token) fails CE0161. So mxcli stores a corrupted constraint when the where-clause contains a [%…%] system token — consistent with nested-[ ] mishandling (the token's inner brackets being treated as constraint delimiters). Independent of the comparison member ([System.owner='[%CurrentUser%]'] fails the same way).

Full mxcli diag --bundle tar.gz available on request (GitHub comments can't attach binaries) — happy to email or paste any specific file from it.

[ako]

Fixed on the issues branch (commits 15ed08f80 + c594b226d), pending merge to main.

Investigation: the title's premise — [%…%] tokens fail — was only partly right, and the root cause was not nested-bracket corruption. Three distinct things:

1. Quoted tokens store correctly. [DueDate < '[%CurrentDateTime%]'] and [System.owner = '[%CurrentUser%]'] pass mx check (the latter once owner is enabled). The reporter's [Title = '[%CurrentUser%]'] is a type mismatch (String attribute vs a User token) — invalid Mendix XPath regardless of mxcli.

2. System.owner needs enabling. [System.owner = '[%CurrentUser%]'] fails CE0161 only when the entity doesn't store owner (it fails even with no token, e.g. [System.owner != empty]). Enable with alter entity X add attribute owner: autoowner and it passes. mxcli now flags this at mxcli check -p <app> --references with the exact fix hint (MDL reference check) — for existing project entities.

3. Real bug found & fixed: bare token inside brackets. where [DueDate < [%CurrentDateTime%]] (unquoted token in a bracketed constraint) was stored unquoted → CE0161, on both the microflow-retrieve and page-datasource paths. normalizeXPathTokens now requotes bare [%…%] to '[%…%]' (already-quoted tokens untouched; multi-predicate preserved). Verified: bare and quoted forms store identically and mx check = 0 errors.

Verification (Mendix 11.11.0): owner-filter + DateTime token (bare and quoted) across microflow and page datasource all store the quoted token and pass mx check with 0 errors. Covered by unit tests (normalizeXPathTokens, validateRetrieveConstraints/regex) and mdl-examples/bug-tests/641-xpath-token-and-owner.mdl. The xpath-constraints skill now documents token typing, the enable-owner requirement, and that bare tokens auto-quote.