refactor(deps): move off the deprecated v1 BSON driver entirely

[ako]

Why

go.mongodb.org/mongo-driver v1.17.10 is removed. mxcli now runs on mongo-driver/v2 v2.9.2 alone, and go version -m bin/mxcli lists only v2.

It was the last component on a customer's blocking dependency scan, flagged for CVE-2026-107325, which has no fix on the v1 line and never will — v1.17.10 is that line's final release and the module is marked deprecated. mxcli was never exposed (the panic is in bsoncore.Array.Validate, which no file imported, as established in ako/mxcli#1493) but the finding would have recurred on every scan with no upgrade able to clear it.

This is not a find-and-replace

The two drivers decode nested documents into different Go types, and the type assertions mxcli reads them back with were written against v1's. Measured on identical bytes:

destination	v1 nested	v2 nested
bson.D	primitive.D	bson.D	equivalent, no action
bson.M	primitive.M	bson.D	breaks .(bson.M)
map[string]any	map[string]any	bson.D	breaks .(map[string]any)

A failed type assertion is not an error, so the value is silently dropped and the next write emits a document with a property missing — which Studio Pro refuses to merge (the canon.CompletePropertySets class, mendixlabs#1373).

The repo's own tests caught every instance. scheduledevents wrote 13 properties where Studio Pro writes 14; TestNoopRerun_ReportsUnchanged tripped the settings guard ("refusing to write a settings document that would drop every part"); the Atlas layout copies lost their icon and image lookups.

The approach: use the switch v2 already has

Rather than audit the 618 type assertions in the migrated files — where a wrong one compiles clean — this uses v2's own decoder options. New leaf package modelsdk/bsoncompat:

helper	mechanism	restores
UnmarshalDocM	DefaultDocumentM()	nested bson.M, v1's shape
UnmarshalDocMap	DefaultDocumentMap()	nested map[string]any
DMap	—	the bson.D.Map() v2 removed

Applied at 73 call sites, found by how each Unmarshal target was declared, not by reading the call: 39 bson.M destinations and 34 map[string]any.

Three things that are easy to get wrong, all documented at the helpers:

• The two Unmarshal helpers are not interchangeable. bson.M is a named type (type M map[string]any), so a bson.M value does not satisfy .(map[string]any). mdl/executor's TestResolveWebServiceName_ReadsMapDecodedDocuments already existed for that exact confusion — "cost a debugging round" — and caught this migration too, because it pins its own precondition rather than passing vacuously. Worth copying that pattern.
• A bson.D destination needs neither helper; applying one there re-introduces the bug inverted.
• bsoncompat cannot live in modelsdk/codec: codec imports modelsdk/mpr, which imports canon and meta, whose own tests could then not import codec at all (import cycle not allowed in test). It depends on nothing inside mxcli so every layer can use it.

Guards against regression

Re-adding v1 is not a build error, and nothing else would notice until the next dependency scan.

• TestNoV1DriverImports — walks the tree for the v1 import path
• TestGoModDoesNotRequireV1Driver — reads go.mod, which is what the scanner reads
• TestDecodeShapes — pins all three nested shapes, and fails loudly if a driver release makes a helper unnecessary rather than passing vacuously

Controls: with a v1 import and the go.mod require restored, the first names modelsdk/element/zz_ctl_v1.go and the second names the go.mod line.

These guards earned their keep immediately. Merging origin/main brought in ako/mxcli#1495 (ALTER NAVIGATION / ALTER MENU), whose 7 new files import v1. The merge was conflict-free so nothing else flagged them; TestNoV1DriverImports failed on the merged tree and named them. They're migrated in the second commit — all bson.D destinations, so import-path-only.

Third commit: the dead test that blocked go mod tidy

go mod tidy could not run in this repo at all, which is why the v1 requirement was first dropped by hand. The cause was not a dependency problem: mdl/exprcheck/roundtrip_test.go imported mdl/backend/mpr (the legacy engine, deleted) plus executor.GetHierarchyForMining and executor.DescribeMicroflowToString (both removed). It never broke a build because it sat behind //go:build roundtrip — a tag no Makefile target and no CI job has ever passed, and the only file in the tree using it. So it rotted through the engine deletion and two API removals without one red build, and tidy — which considers every build tag — was the only thing that still saw it.

Ported rather than deleted, to mdl/executor/exprcheck_roundtrip_test.go under the integration tag: describing every microflow and re-parsing each expression with the robust parser catches grammar gaps (a missing parsePrimary branch, funcTable entry or slot constraint) that the unit tests cannot, since those only feed the parser expressions someone thought to write down. It now runs under make test-integration-executor, and fails rather than passing silently when the fixture yields no microflows or no expression slots.

With that gone, go mod tidy runs clean and pruned 35 more stale go.sum lines than the hand-edit had — so v1's removal is now the tool's work rather than mine.

This is a third concern on the branch. It is folded in because the proper tidy of go.mod/go.sum in this PR depends on it; happy to split it out if you'd rather review it separately.

Verification

• go build ./... clean, go vet clean (also under -tags integration), gofmt clean
• 106 test packages pass, 0 failures (on the merged tree, with origin/main including feat(navigation): alter navigation / alter menu — item-level menu edits #1495)
• Zero v1 imports remain
• go mod tidy exits 0; go mod verify — all modules verified
• go version -m bin/mxcli lists only mongo-driver/v2 v2.9.2
• Findings recorded; make check-findings passes

The integration (parity) and integration (roundtrip) suites are the real gate here — they exercise the byte-exactness this change could plausibly disturb. Worth waiting for them specifically. integration (executor) is what exercises the ported test; it skips in a container without an mx-test-projects/ checkout, which is why I could not run it locally.

One note for the reviewer

bsonv2 aliases are left as they are — 39 references in files that only ever imported v2 and named it bsonv2 to distinguish it from v1. The name is still accurate, so renaming would be churn in an already large diff.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Rer1mzP69XxbXKxQqheipM

[ako]

Tested this against the Formula1 solution — two Mendix 11.14.0 apps, 1,060 units, 41 MDL scripts. No regression found.

Your description names the failure mode as a silently dropped property on the next write, which is a claim about written bytes, so I compared bytes. Head 36f8cc426 against base 4c0e494e8 (main), both built here, with the base as a control throughout.

The premise

go version -m mxcli   (PR head)   dep go.mongodb.org/mongo-driver/v2 v2.9.2
go version -m mxcli   (base/main) dep go.mongodb.org/mongo-driver     v1.17.10
                                  dep go.mongodb.org/mongo-driver/v2  v2.9.2

Zero v1 import paths in the tree, go.mod requires only v2, and the control build pulling v1.17.10 while this one does not is the claim in its clearest form. Your three guards pass, and TestDecodeShapes is written so it cannot pass vacuously — the trap subtest t.Fatals if the driver ever starts behaving, naming the reason. scheduledevents and TestNoopRerun_ReportsUnchanged pass here too.

Same bytes, where bytes are deterministic

Re-exec of the whole set against the already-provisioned project, from identical committed bytes, with each build:

                        writes   files touched
base run 1 (main)          20          23
base run 2 (main)          20          23
PR head                    20          23

Write lists identical, line for line. The byte comparison needs a noise floor first, because two runs of the same binary don't agree:

same binary, two runs:   7 of 23 files differ
PR vs base:              7 of 23 files differ — exactly the same 7

So all 16 files whose content is deterministic at all are byte-identical to main, and the 7 that differ are the 7 that differ anyway (five pages are Replaced rather than spliced, so a rebuild renumbers element IDs — my project's scripts, not yours).

For the specific failure mode, after the PR build had done its writes:

Formula1Backend   Checked 519 unit(s) … Every unit already has the property names Studio Pro writes.
Formula1Frontend  Checked 541 unit(s) … Every unit already has the property names Studio Pro writes.

Both fix hashes-clean, unit counts unchanged.

Your three named areas, round-tripped

described and the output re-executed:

• Scheduled event (the 13-vs-14 properties case) → Unchanged scheduled event: Formula1Backend.SE_NarrativeBuild
• Settings (the "would drop every part" guard) → 4 documents already in sync, guard not tripped
• Icon lookups → Unchanged navigation profile 'Responsive', all 8 menu items keeping their Atlas_Core.Atlas.* icons, hyphenated quoted ones included ("time-clock", "org-chart", "user-neutral-group", "layout-list")

Also: both script sets check with 0 errors, both apps build and boot at build #1 with no CE codes, all six published OData services return 200 with real rows through x-api-key microflow auth, and playwright check passes with svg.marks>=1.

Two notes, neither about this PR

• The full re-exec writes 20 documents on main as much as on this branch, so that non-idempotency is pre-existing. Chasing it found a real gap on my side of the line: a relative MetadataUrl ('./contracts/f1-metadata.xml') is stored resolved to an absolute file:///workspaces/… URL, so the committed model carries the authoring container's path and five OData clients churn whenever the checkout path changes. Filed separately rather than here.
• playwright check <url> fails a page it has just signed into and rendered; the same command without the URL passes #1216 (playwright check <url> failing a page it has signed into and rendered) reproduces unchanged on this build, as expected for an unrelated branch.

One caveat on scope: integration (executor) skips here too, so the ported exprcheck round-trip test is the part I could not exercise. Everything above is the written-model side.

Recorded as §93 of FINDINGS.md in ako/mxcli-formula1.

---

Generated by Claude Code