create association to System.User fails at exec (child entity not found) but passes check/diff

[ako]

Summary

create [or modify] association ... to System.User (or any System-module target) passes mxcli check --references and mxcli diff, but fails at mxcli exec with:

Error: child entity not found: System.User

So the failure only appears when actually writing — the validation/preview paths green-light it. This is also a concrete instance of the broader "check vs execute divergence" feedback.

Reproduction (verified on test5, Mendix 11.9.0)

create or modify association MyFirstModule.Cars_Owner
  from MyFirstModule.Cars to System.User;

$ ./bin/mxcli check  t.mdl -p test5.mpr --references   →  ✓ All references valid / Check passed!
$ ./bin/mxcli diff   -p test5.mpr t.mdl                →  + ... from MyFirstModule.Cars to System.User  (Summary: 1 new)
$ ./bin/mxcli exec   t.mdl -p test5.mpr                →  Error: child entity not found: System.User

(SHOW ENTITIES / catalog list the 39 System entities, so the data is present — it's the resolver that misses them.)

Root cause — two divergent entity resolvers

• check/diff resolve references via buildEntityQualifiedNames (mdl/executor/helpers.go:433), which includes System-module entities → check passes.
• exec (write path) resolves the TO/"child" entity via findEntity (mdl/executor/oql_type_inference.go:660). That function iterates ctx.Backend.ListDomainModels() and matches modName == moduleName + entity.Name == entityName, but does not resolve the virtual System domain model's entities → returns mdlerrors.NewNotFound("child entity", "System.User") at mdl/executor/cmd_associations.go:51.

The parent (FROM) side hits the same findEntity, so a from System.X would fail symmetrically.

The high-level fluent API has its own copy of this error (api/domainmodels.go:581) via GetEntity, with the same gap.

Workaround (user-reported)

alter association Mod.Assoc set owner Default; works because execAlterAssociation (cmd_associations.go:218) operates on an existing association by name and never resolves the child entity. (Note: set owner is required — bare owner is a reserved keyword.) Not a real substitute, since you can't create the association in the first place.

Proposed fix

Make findEntity (executor write path) resolve System-module entities the same way buildEntityQualifiedNames does — i.e. include the virtual System domain model when iterating, or special-case the System module. Add an exec test creating ... to System.User. Optionally align api/domainmodels.go GetEntity too.

This is the kind of gap that mxcli check should not pass while exec fails — see also the umbrella "check vs mx check / check vs exec divergence" feedback.

Reported via external user feedback.

[github-actions]

Issue Triage

Summary:
Creating or modifying an association to a System‑module entity (e.g., System.User) passes mxcli check and mxcli diff but fails during mxcli exec with “child entity not found”.

Checklist for bug report completeness

Required info	Present?	Details
mxcli version	❌	Not mentioned
Mendix version	✅	Mendix 11.9.0 (stated in reproduction)
Scenario (what the user tried)	✅	MDL script create or modify association … to System.User and the three CLI commands (check, diff, exec)
Expected output	✅	exec should succeed (association created/modified)
Experienced output	✅	Error: child entity not found: System.User
AI bug report (mxcli diag --bundle or session log)	❌	Not provided

What’s missing

• The exact mxcli --version (or commit/build identifier) used.
• A diagnostic bundle (mxcli diag --bundle) or at least the session log showing the environment and any internal state.

Polite request
Could you please add the mxcli version (output of mxcli --version) and, if possible, run mxcli diag --bundle and attach the resulting archive? That will help us reproduce the issue and verify the fix. Thanks!

---

Automated triage via OpenRouter — workflow source