Other parsers share #583's narrow-int32 assertion: silently zeroes numeric fields when Studio Pro writes them as int64

[ako]

Summary

PR #584 fixed the BSON-numeric-width bug for StringAttributeType.Length. The same narrow raw[\"X\"].(int32) pattern lives in several other parsers, each of which will silently report 0 for any value Mendix Studio Pro writes as BSON int64 (the same divergence that produced #583).

Affected fields

File:Line	Field	What surfaces silently as 0/unlimited
sdk/mpr/parser_misc.go:762	MinOccurs (JSON Structure element)	JSON-structure occurrence constraints
sdk/mpr/parser_misc.go:765	MaxOccurs (JSON Structure element)	JSON-structure occurrence constraints
sdk/mpr/parser_misc.go:774	MaxLength (JSON Structure element)	XSD/JSON maxLength facet, used for import/export mapping validation
sdk/mpr/parser_misc.go:777	FractionDigits (JSON Structure element)	Decimal precision in JSON structures
sdk/mpr/parser_misc.go:780	TotalDigits (JSON Structure element)	Decimal precision in JSON structures
sdk/mpr/parser_enumeration.go:200	Interval (scheduled event)	Scheduled-event interval value — would show as 0 → "never runs" in describe output

Also worth tidying (not buggy, but verbose):

• sdk/mpr/parser_microflow_actions.go:295-301 (NumberOfPagesToClose) already handles both int32 and int64 with an if/else chain. Collapsing to extractInt(...) keeps the codebase consistent with the fix #583: parse StringAttributeType.Length across BSON numeric widths #584 fix.

Out of scope (don't touch):

• parser.go:96/111/177 and parser_microflow_actions.go:249/270 — these intentionally probe for int32 because Mendix array-prefix markers really are stored as int32. The assertion is a type-discriminator, not a value read.

Proposed fix

For each row in the table, replace the narrow assertion with the existing extractInt(raw[\"X\"]) helper from sdk/mpr/parser.go:44, which accepts int32/int64/int/float64. Same pattern as #584.

Add unit tests in sdk/mpr/parser_misc_test.go and sdk/mpr/parser_enumeration_test.go (or parser_scheduledevent_test.go if the function is moved) parametrised on numeric width, mirroring TestParseAttributeType_StringLength_BsonNumericWidths from PR #584.

How this is likely to bite

Same pattern as #583: an AI agent (or a fixture script) reads MaxLength/MaxOccurs from mxcli describe import-mapping or mxcli describe json-structure, generates payloads under the assumption that no limit applies, and gets runtime rejections from Mendix's XSD validator. Scheduled-event misreport is more visible — describe output would show interval 0 for events that actually run on a real cadence.

Verification approach

For each affected field: hand-craft a BSON document (map[string]any{...}) with the field stored as int64, call the parser directly, assert the field is preserved. The Go unit test from #584 is a one-file template — copy-paste, swap the field name, and you have the failing test in one step.

Notes

• Root-cause analysis lives in PR fix #583: parse StringAttributeType.Length across BSON numeric widths #584 / issue describe entity and CATALOG.ATTRIBUTES misreport String attribute lengths #583.
• The .claude/skills/fix-issue.md symptom table already has a row for "narrow int32 assertion on a numeric field" pointing at this fix pattern (added in fix #583: parse StringAttributeType.Length across BSON numeric widths #584), so the next contributor matching the symptom lands here.

[github-actions]

Issue Triage

Summary
The issue reports that several parsers in mxcli use a narrow int32 assertion that silently returns 0 when Mendix Studio Pro writes the corresponding BSON field as int64, affecting fields such as MinOccurs, MaxOccurs, MaxLength, FractionDigits, TotalDigits, and scheduled‑event Interval.

Checklist of required bug‑report information

Required info	Present?	Notes
mxcli version	❌	Not mentioned
Mendix version	❌	Not mentioned
Scenario (what the user was trying to do)	❌	No description of the command or workflow that triggered the problem
Expected output	❌	Not stated what the correct values should be
Experienced output	❌	No error message, wrong result, or crash details provided
AI bug report (mxcli diag --bundle or session log)	❌	Not included

Next steps
Could you please add the missing details so we can reproduce and verify the fix? Specifically:

1. The version of mxcli you’re using (output of mxcli --version or commit/build info).
2. The Mendix version of the project you’re processing (e.g., 10.6, 9.24).
3. The exact scenario/command you ran (e.g., mxcli describe json-structure … or an MDL script).
4. What you expected to see for the affected fields versus what you actually observed (including any error messages or incorrect values).
5. If possible, a diagnostic bundle from mxcli diag --bundle or at least the relevant session log.

Once we have that information, we’ll be able to confirm the issue and move forward with the proposed fix. Thank you for bringing this to our attention!

---

Automated triage via OpenRouter — workflow source