fix: CREATE OBJECT writes associations as attributes, DECLARE treats entities as enumerations (CE1613)

[engalar]

Summary

When mxcli exec generates microflows with CREATE/CHANGE OBJECT activities, two related bugs cause invalid BSON that produces CE1613 errors in Studio Pro (and can crash Studio Pro during version control status refresh with System.InvalidOperationException: Sequence contains no matching element).

Bug 1: Association stored in Attribute field (ChangeActionItem)

Location: mdl/executor/cmd_microflows_builder_actions.go:106 (and line 262)

The executor uses strings.Contains(change.Attribute, ".") to distinguish associations from attributes:

if strings.Contains(change.Attribute, ".") {
    memberChange.AssociationQualifiedName = change.Attribute
} else if entityQN != "" {
    memberChange.AttributeQualifiedName = entityQN + "." + change.Attribute
}

This heuristic fails because association names in MDL don't contain dots (e.g. Child_Parent), so they are misclassified as attributes.

Result: The BSON ChangeActionItem writes the association name into the Attribute field instead of the Association field:

// WRONG (current)
{ "Association": "", "Attribute": "Demo.Child.Child_Parent" }

// CORRECT
{ "Association": "Demo.Child_Parent", "Attribute": "" }

Studio Pro error:

[CE1613] "The selected attribute 'Demo.Child.Child_Parent' no longer exists."

Bug 2: Entity type treated as Enumeration in DECLARE

Location: mdl/visitor/visitor_helpers.go:365

buildDataType() defaults bare qualified names (e.g. Demo.Parent) to TypeEnumeration:

// Handle bare qualified name (entity reference or enumeration)
if qn := dtCtx.QualifiedName(); qn != nil {
    return ast.DataType{Kind: ast.TypeEnumeration, EnumRef: &name} // ← always enum!
}

When a DECLARE statement uses an entity type (DECLARE $Item Demo.Parent = empty), the visitor cannot distinguish it from an enumeration type and defaults to enum.

Result: The BSON CreateVariableAction.VariableType uses DataTypes$EnumerationType instead of DataTypes$ObjectType:

// WRONG (current)
{ "$Type": "DataTypes$EnumerationType", "Enumeration": "Demo.Parent" }

// CORRECT
{ "$Type": "DataTypes$ObjectType", "Entity": "Demo.Parent" }

Studio Pro error:

[CE1613] "The selected enumeration 'Demo.Parent' no longer exists."

Root Cause

Both bugs share the same root cause: the visitor and executor lack access to the domain model catalog, so they cannot determine whether a qualified name refers to an entity, enumeration, or association. They rely on fragile heuristics (presence of . in name, or defaulting to one type) instead of querying the catalog.

Minimal Reproduction

CREATE PERSISTENT ENTITY Demo.Parent (
  Name: String(100)
);

CREATE PERSISTENT ENTITY Demo.Child (
  Label: String(100)
);

CREATE ASSOCIATION Demo.Child_Parent
  FROM Demo.Child TO Demo.Parent;

-- Bug 1: Association in CREATE OBJECT
CREATE MICROFLOW Demo.Bug1 ()
BEGIN
  $Parent = CREATE Demo.Parent (Name = 'test');
  $Child = CREATE Demo.Child (
    Label = 'test',
    Child_Parent = $Parent);
END;
/

-- Bug 2: Entity type in DECLARE
CREATE MICROFLOW Demo.Bug2 ()
BEGIN
  DECLARE $Item Demo.Parent = empty;
END;
/

Run with: mxcli exec repro.mdl -p app.mpr, then mx check app.mpr to see CE1613 errors.

Suggested Fix

The executor should query the catalog (or domain model) to resolve names:

1. Bug 1: Before building ChangeActionItem, look up the member name against the entity's attributes and associations. If found in associations, set AssociationQualifiedName; otherwise set AttributeQualifiedName.

2. Bug 2: In buildDataType(), when encountering a bare qualified name, the resolver should check the catalog to determine if it's an entity or enumeration and return the correct DataType.Kind. As a fallback (when no catalog is available, e.g. mxcli check without -p), the current default-to-enum behavior could remain, but a warning should be emitted.

[github-actions]

Issue Triage

Summary:
The issue reports that mxcli exec creates invalid BSON for CREATE/CHANGE OBJECT activities and DECLARE statements, leading to CE1613 errors in Studio Pro.

Checklist for bug report completeness

Required info	Present?	Details
mxcli version	❌	Not mentioned
Mendix version	❌	Not mentioned
Scenario (what the user was trying to do)	✅	Described: running mxcli exec repro.mdl -p app.mpr then mx check app.mpr
Expected output	✅	Implicit: valid BSON, no CE1613 errors
Experienced output	✅	CE1613 error messages and possible crash described
AI bug report (mxcli diag --bundle or session log)	❌	Not provided

Missing information
To help us investigate, could you please add:

1. The version of mxcli you’re using (mxcli --version or commit/build info).
2. The Mendix version of the project you’re processing (e.g., 10.6.x, 9.24.x).
3. If possible, a diagnostic bundle (mxcli diag --bundle) or at least the session log from the failing run.

Once we have those details, we’ll be able to reproduce the issue and work on a fix. Thanks for the thorough report!

---

Automated triage via OpenRouter — workflow source

[engalar]

Additional info requested by triage:

• mxcli version: v0.3.0-37-g686e5ab (built 2026-03-29)
• Mendix version: 11.6.4
• Diagnostic bundle: Not applicable — the bugs are in code generation logic, fully reproducible from the MDL script in the issue description. No runtime state needed.

The root cause is confirmed by source code analysis:

1. cmd_microflows_builder_actions.go:106 — strings.Contains(change.Attribute, ".") heuristic
2. visitor_helpers.go:365 — buildDataType() defaults to TypeEnumeration

Both are deterministic code paths, independent of environment.

[ako]

Investigated and fixed

Both bugs confirmed and fixed.

Bug 1: Association in CREATE/CHANGE OBJECT

Root cause: strings.Contains(change.Attribute, ".") heuristic — association names like Child_Parent don't contain dots, so they were misclassified as attributes.

Fix: New resolveMemberChange() helper queries the domain model to check if a member name matches an association on the entity. Falls back to the old heuristic when no reader is available.

Verified via BSON dump:

// Before: "Association": "", "Attribute": "Demo.Child.Child_Parent"
// After:  "Association": "Demo.Child_Parent", "Attribute": ""

Bug 2: Entity type in DECLARE

Root cause: buildDataType() in the visitor defaults bare qualified names to TypeEnumeration (known ambiguity documented in CLAUDE.md). The executor's addCreateVariableAction passed this through without correction.

Fix: addCreateVariableAction now checks if a TypeEnumeration qualified name is actually an entity by querying the domain model via isEntity(). If it is, the type is corrected to TypeEntity before building the BSON.

Verified via BSON dump:

// Before: "$Type": "DataTypes$EnumerationType", "Enumeration": "Demo.Parent"
// After:  "$Type": "DataTypes$ObjectType", "Entity": "Demo.Parent"

Both fixes are domain-model-aware and fall back gracefully when no reader is available (e.g., mxcli check without -p).