Fix an unqualified association datasource that wrote an unloadable page (#854 follow-on)

[ako]

Investigating upstream #854 found the reported bug already fixed and a second, unreported crash in the same code still live. This fixes the second one.

Verified against mxbuild 11.13.0 throughout.

mendixlabs#854 as filed does not reproduce

Two commits landed on 6 Aug — the day the issue was filed, and after the v0.16.0 the reporter used: f0d1aea resolves cross-module associations through CrossAssociations, and 18de30b refuses to write an unresolved destination at all.

Built the pre-fix parent (a306810) and ran the same qualified script on both, changing one variable:

association	DestinationEntity (pre-fix)	mx check (pre-fix)
ModA.Order_Note (same module)	ModA.Note	loads
ModA.Order_Line (→ ModB.Line)	""	ArgumentNullException at set_DestinationEntityId

Which is the reporter's claim exactly, including "same-module works". On main both resolve and mx check reports 0 errors.

Worth recording the misstep: the first attempt ran bare names pre-fix and qualified names post-fix. Two variables, so the "reproduction" showed nothing about cross-module. Holding the script constant across the two builds is what isolated it.

What is still broken

An EntityRefStep has two BY_NAME halves and Mendix resolves either one it cannot find to null. Only the destination was guarded. So on current main:

datagrid dgLines (datasource: association Order_Line/ModB.Line)

writes Association: "Order_Line" — unqualified — and the project dies on load:

An error occurred when trying to set the 'Association' property of a Entity ref step
---> System.ArgumentNullException: Value cannot be null. (Parameter 'value')
    at ...DomainModels.Refs.EntityRefStep.set_AssociationId

Same unopenable project as mendixlabs#854, one property over.

The explicit-destination form is what makes it reachable: supplying the destination satisfies the empty-DestinationEntity guard, so nothing else stood between a bare name and the crash — and Assoc/Module.Entity is precisely the spelling that guard's error message tells the author to use. The fix's own advice walked you into the adjacent crash.

The change

In buildDataSourceV3's association case:

• Qualify a bare association with the context entity's module via resolveAssociationPathIn — the rule attribute-path hops already follow, and the one the skill documents.
• When the author supplies a destination, verify the association exists via associationEndpoints instead of taking it on trust. A misspelled (or wrongly-moduled) name would otherwise be written qualified-but-nonexistent and null exactly the same way; the refusal names the context entity so the "declared in another module" case is actionable.

Both halves of the step are now guarded, not just the reported one.

Verification

Five spellings, all resolving to ModA.Order_Line / ModB.Line:

authored	before	after
Order_Note (bare, same module)	refused	resolves
Order_Line (bare, cross-module)	refused	resolves
Order_Line/ModB.Line	writes unloadable page	resolves
ModA.Order_Line	resolves	resolves
ModA.Order_Line/ModB.Line	resolves	resolves

• mx check on the built project: 0 errors, 0 best-practice recommendations.
• New tests fail against unfixed code with the reported symptom (all 5 expected failures, the two already-qualified cases passing) — the fix is shown to be the cause, not just compatible with green.
• it-14-assoc-destination-entity.mdl re-run end to end: the existing System-module forms still resolve, so the new existence check does not regress associations mxcli cannot see in the project's own domain models.
• Full go test ./..., make check-mdl, make check-skill-mdl green.

Two things to know

mx check exits 0 on this class of failure. The loader dies before validation, so anything asserting on $? will call a dead project healthy — assert on the contains: N errors line instead. Noted in the symptom-table row.

make fmt reformats 11 files unrelated to this change that are already unformatted on main. I reverted them rather than bundle unrelated churn, so the tree is not gofmt-clean at HEAD. Worth a separate housekeeping commit.

🤖 Generated with Claude Code

https://claude.ai/code/session_013uQvFDd5R4eNqqita59jM8

---

Generated by Claude Code