Java gauge widens to 60 integration tests — write-error semantics get straightened out
Summary: Java gauge widens to 60 integration tests, write-error semantics get straightened out (v0.5.0b2).
The Java conformance gauge tripled in scope this release — from 19 tests across 5 driver-sync classes to 60 tests across 13 classes, including the unified-spec runners that exercise the wire-level command-logging / command-monitoring / connection-pool-logging protocols. 59 tests pass; 1 fails (testMapReduceWithGenerics, deprecated since MongoDB 5.0). That's a real 98.3% conformance number against the language-canonical Java driver enterprise MongoDB consumers most often use.
Two server-side fixes landed to make the wider scope green. First, the update and delete command handlers now catch QueryError from malformed filter operators (the test framework probes us with {$unsupported: 1}) and surface them as per-op writeErrors with ok: 1 instead of failing the whole command — that's the wire shape mongo-java-driver's CommandMonitoringTest asserts on for all four CRUD-write variants. Second, update now pre-validates the pipeline-update shape (the u: [...] form) at parse time. Unknown stages return a command-level ok: 0 with code 168 InvalidPipelineOperator, matching mongod's strict path. That's required by CommandLoggingTest so the driver logs Command failed rather than Command succeeded when a malformed pipeline arrives.
Four classes are excluded as out-of-scope, each documented in java_validation/include_modules.py: ExplicitUuidCodecUuidRepresentationTest (UUID legacy/standard binary subtype id-key normalization, its own slice), CollectionManagementTest (clustered indexes + time-series — 5.0+ features), CrudProseTest (writeErrors[].errInfo rich validation-error details), and ServerSelectionLoggingTest (needs configureFailPoint closeConnection: true mode — we only support errorCode / writeConcernError modes today).