What does validationAction warn do when a MongoDB write violates the collection validator?

## The failure knob A collection validator has two companion options. `validationLevel` decides which writes are checked; `validationAction` decides what happens when a checked write fails. `validationAction` takes exactly two values: `"error"` (the default) and `"warn"`. ## error With `"error"`, a failing write does not happen. The client receives a write error — the familiar "Document failed validation" — and, on currently shipping versions (this detail was added in MongoDB 5.0), an `errInfo` object describing *why*: which schema rules were violated, at which field path, and what the offending value was. Before that, the error text told you almost nothing, which is the historical reason many teams still write their validators with a `description` on every property; the description is echoed in the failure output. The important consequence is transactional-shaped: the operation is refused, so the caller has to handle it. In a bulk write, whether the rest of the batch proceeds depends on whether the batch is ordered — an ordered `bulkWrite` stops at the first failure, an unordered one continues and reports the failures at the end. ## warn With `"warn"`, the outcome flips. The write is applied — the non-conforming document is now in the collection — and the violation is recorded as a warning in the `mongod` log rather than returned to the caller. The client sees success. Nothing in the application changes behaviour. That makes `warn` a measurement instrument, not a guardrail: - You have written a candidate `$jsonSchema` and you believe your services produce conforming documents, but you do not want to bet a production incident on that belief. - You attach the validator with `validationAction: "warn"` and let real traffic run through it. - Every write that *would* have been rejected shows up in the server log with the failing document's identity, so you can find the service, fix it, and then flip to `error` with evidence rather than hope. ## The catch with warn A warning is only useful if somebody reads it. If mongod logs are not shipped into whatever the team searches, a `warn` validator is functionally identical to no validator: the same bad documents accumulate, silently, with a paper trail nobody opens. Before choosing `warn`, confirm three things — that the logs reach your log store, that you can query them for validation warnings, and that a specific person or alert owns that query for the duration of the rollout. The second catch is drift. `warn` is meant to be temporary. A collection left on `warn` for a year has a schema that describes intent rather than reality, and the eventual flip to `error` becomes as risky as introducing the validator was in the first place. Give the observation window a deadline. ## How it composes with validationLevel The two settings are orthogonal, which yields a useful ladder from most permissive to strictest: 1. `validationLevel: "off"` — nothing is checked. 2. `"moderate"` + `"warn"` — legacy documents are exempt from checking, and failures elsewhere are only logged. 3. `"strict"` + `"warn"` — everything is checked, nothing is blocked; the maximum-signal observation setting. 4. `"moderate"` + `"error"` — new documents and already-clean documents are enforced; legacy documents can still be updated freely. 5. `"strict"` + `"error"` — the default and the destination. A typical rollout walks from 3 to 4 to 5. Note that step 3 gives more signal than step 2, because `moderate` suppresses the check on exactly the legacy documents you are trying to count. ## Setting it ```js db.runCommand({ collMod: "orders", validationAction: "warn" }) ``` and back again with `"error"`. Read it back from `db.getCollectionInfos({ name: "orders" })` — `options.validationAction` — rather than assuming the value carried over from an earlier `collMod`. ## What a strong answer sounds like Name both values, state precisely that `warn` applies the write and logs it while `error` refuses the write and returns the failure to the client, and then say the operational thing: `warn` is an observation mode with a deadline and a prerequisite, which is that someone is actually reading the logs.