fix: augment nested ObjectType properties from .mpk to prevent CE0463

[engalar]

Summary

• Extended AugmentTemplate to recursively sync nested ObjectType PropertyTypes (e.g., DataGrid2 column properties) with .mpk definitions
• Fixes the root cause of CE0463 when installed widget version differs from embedded template version
• Handles add/remove of nested properties in both Type schema and Object values

Root Cause

When the project's .mpk widget version differs from the embedded template version, AugmentTemplate only synced top-level properties. Nested ObjectType properties (like DataGrid2 column properties: tooltip, exportValue, showContentAs) were left with the original template's schema, causing Type/Object property count mismatches that trigger CE0463.

What Changed

• augment.go: Added augmentNestedObjectType() that processes .mpk children for Object-type properties
• Fixed early return that skipped nested processing when top-level had no changes
• augment_test.go: Added test for nested ObjectType property addition

Relationship to #164

PR #164 adds mx update-widgets as a workaround before mx check. This PR fixes the underlying cause so the workaround is needed less often.

Refs #121

Test plan

• Existing augmentation tests pass (8/8)
• New nested ObjectType augmentation test passes
• go build ./... and go vet pass
• Integration test with DataGrid2/ComboBox/Gallery on mismatched widget versions

🤖 Generated with Claude Code

[github-actions]

AI Code Review

What Looks Good

The PR successfully addresses the CE0463 bug by extending the AugmentTemplate function to handle nested ObjectType properties. The changes are focused, well-tested, and follow the existing code patterns.

Key strengths:

• Correct root cause fix: Properly handles the version mismatch scenario by syncing nested properties (like DataGrid2 column properties) that were previously ignored
• Atomic changes: Single, clear purpose - fixing nested property augmentation without mixing concerns
• Comprehensive test: New test case validates both PropertyTypes and WidgetObjects are updated for nested properties
• Logical flow:
  • Fixes premature return that skipped nested processing when top-level had no changes
  • Adds augmentNestedObjectType() that correctly navigates BSON structure to sync nested PropertyTypes and Properties
  • Handles both addition and removal of nested properties
• Code quality:
  • Uses existing helper functions (getMapField, getArrayField)
  • Proper error handling with context
  • Clear comments explaining the complex BSON navigation
  • Consistent with existing augmentation patterns

Test coverage:

• New test TestAugmentTemplate_NestedObjectType_AddMissing covers:
  • Template with Object-type property containing one nested property
  • .mpk definition with additional nested property
  • Verification that both PropertyTypes and WidgetObjects get the new nested property
  • Proper counting logic that skips BSON array markers

Recommendation

Approve - The PR is ready for merge. It correctly fixes the CE0463 issue with minimal, focused changes, includes appropriate test coverage, and maintains code quality standards. No blocking issues identified.

---

Automated review via OpenRouter (Nemotron Super 120B) — workflow source

[ako]

Substantial fix targeting the root cause that PR #164 was working around. The approach is correct.

What's good

• Recursive sync of nested ObjectType PropertyTypes correctly handles add/remove for both Type schema and Object Properties
• Early-return fix is critical: previously if len(missing) == 0 && len(stale) == 0 { return nil } would skip nested processing when top-level was already in sync. Now checks hasNestedChildren.
• Exemplar-based cloning with createPropertyPair fallback
• TypePointer matching correctly identifies which Object Properties to update for stale removal

Concerns

Test coverage is thin. Only one test case (add missing). Missing:

• Removing stale nested properties (the ~50 lines of removal logic)
• Multiple WidgetObject instances (e.g., DataGrid with 3 columns — does the new property get added to all 3?)
• No-op case when nested is already in sync (regression guard for the early-return change)

Recursion depth. The function syncs one level of nesting. Worth confirming this is sufficient for all Mendix widget specs — does any widget have nested-nested ObjectTypes?

Unhandled: type change between versions. If .mpk changes a child from string → textTemplate, the function neither removes nor updates the type. Probably out of scope but worth noting.

Minor: The break in augmentNestedObjectType's objProps loop after finding matched TypePointer would benefit from a comment explaining why (only one property matches a given TypePointer).

LGTM — fix is correct for the documented scenario. Recommend expanding test coverage for stale removal and multi-instance cases in a follow-up.