Repository navigation
fix(test): point container_rendermode_test at the v2 BSON driver - #1500
Merged
Merged
Conversation
main is red. The merge of #1497, which removed go.mongodb.org/mongo-driver v1 from go.mod, landed just after #1498 added mdl/backend/pagemutator/container_rendermode_test.go — a file written against v1. The package now fails to compile at all: container_rendermode_test.go:8:2: no required module provides package go.mongodb.org/mongo-driver/bson FAIL github.com/mendixlabs/mxcli/mdl/backend/pagemutator [setup failed] and TestNoV1DriverImports names the file, which is what it is for. Neither PR is at fault. #1498 was authored and tested against a main that still required v1, the two touched different files so nothing conflicted, and each was green on its own base. The combination is what breaks. The file uses bson.D only, so this is the import path and nothing else: v2 nests bson.D inside bson.D exactly as v1 nested primitive.D, so its assertions are already correct and it needs no modelsdk/bsoncompat helper. Checked the whole tree rather than just the file CI named, since `go test` stops at the first [setup failed] package and a second offender would only surface on the next run: this is the only one. Verified: go build ./... clean, go vet clean, gofmt clean, 106 test packages pass with 0 failures, the two packages that failed in CI (mdl/backend/pagemutator and modelsdk/bsoncompat) both pass, and `go mod tidy` exits 0 leaving go.mod and go.sum unchanged — so v1 stays out. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Rer1mzP69XxbXKxQqheipM
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
main is red — one-line fix
ako/mxcli#1497, which removed
go.mongodb.org/mongo-driverv1 fromgo.mod, merged just after ako/mxcli#1498 addedmdl/backend/pagemutator/container_rendermode_test.go— a file written against v1. The package no longer compiles:Neither PR is at fault. #1498 was authored and tested against a
mainthat still required v1; the two touched different files so nothing conflicted; each was green on its own base. Only the combination breaks.The file uses
bson.Donly, so this is the import path and nothing else — v2 nestsbson.Dinsidebson.Dexactly as v1 nestedprimitive.D, so its assertions are already correct and it needs nomodelsdk/bsoncompathelper.I checked the whole tree, not just the file CI named, since
go teststops at the first[setup failed]package and a second offender would only surface on the next run. This is the only one.Verification
go build ./...clean,go vetclean,gofmtcleanmdl/backend/pagemutatorandmodelsdk/bsoncompatgo mod tidyexits 0 leavinggo.modandgo.sumunchanged — v1 stays outWorth a repo setting, not more code
This is the second time a concurrently-authored PR re-added the v1 import — the first was #1495, caught in-branch when I merged
origin/maininto #1497.TestNoV1DriverImportsnamed the file both times, which is exactly its job: a re-added import is not a build error while the module is still required, and after removal the compile error names only the package, not the reason.The structural fix is require branches to be up to date before merging, at least for the window around a dependency removal. Any PR open at the moment a shared module is dropped is still written against it, and nothing in the diff of either side reveals the conflict.
Generated by Claude Code