MongoDB Community Server 9.0.2 can return {ok: 1} for a collMod upgrade from a prepared validationLevel: "strict" / validationAction: "warn" collection to validationLevel: "constraint" / validationAction: "error" while a concurrent update makes an already-scanned document violate the validator. The final collection options are constraint/error, but one noncompliant document remains. Later invalid writes are rejected, and a separate clean-restart test shows that the inconsistent state persists.

Expected: MongoDB documents that the constraint level guarantees every document in the collection satisfies the validator, and that the upgrade scan fails collMod when it finds a violation. A successful upgrade should preserve that invariant even when an update races with the scan.

Actual: In three consecutive ordinary local 9.0.2 runs, collMod returned ok:1, the concurrent update succeeded, and the final collection had one invalid document under constraint/error. A separate test-only scan barrier confirmed that the update completed while the upgrade scan was paused before the final metadata change. The ordinary reproductions did not require test commands or failpoints.

Tested environment: MongoDB Community Server 9.0.2, Windows x64 standalone, gitVersion c4d309807b94ac30edcca32e35e88a9598eadfc8, Python 3.11, PyMongo 4.18.2, synthetic localhost-only data.

This is a product correctness report. The writer is permitted to update documents under the prior warn action; no privilege escalation or security boundary violation is claimed.

Documentation: https://www.mongodb.com/docs/manual/core/schema-validation/specify-validation-level/
Related issue: SERVER-134758 concerns how validate reports an already noncompliant constraint collection. This ticket concerns the concurrent update path that creates that state while collMod reports success.