v3.1.0
ShedLock 7.x now runs against the embedded emulator, with MongoDB concern and preference settings carried faithfully through every client view and every new boundary checked against real MongoDB.
Highlights
- 01
ShedLock 7.x locks against the emulator
ShedLock's MongoLockProvider now boots and acquires contended locks under Bonsai. The release pins that customer path with an end-to-end pair that runs once through the shim and once through passthrough against a real server.
Read the guide → - 02
Concern and preference settings carry through
Write concern, read concern and read preference now flow from client settings through client, database and collection views with the driver's inheritance rules and matching getters. Satisfiable write concerns, all read-concern levels and all read preferences are accepted.
Read the guide → - 03
Unsupported topologies refuse by name
Multi-node write concern, unacknowledged writes and replica-set tag modes fail at settings, transaction or view construction with named compatibility keys, instead of hanging or silently discarding the caller's configuration.
Read the guide → - 04
findAndModify reports the right duplicate-key family
A conflicting findOneAndUpdate or findOneAndReplace upsert now raises the command-channel DuplicateKey result MongoDB returns, while update-command upserts retain their write-error family. The differential lane caught and pins the distinction.
Read the guide →
Full notes
Added
- Client, database and collection write concern, read concern and read preference views carry configured values, inherit them as the MongoDB driver does, and expose them through the corresponding getters. The Spring shim harvests application MongoClientSettings and customizer values at context refresh, allowing ShedLock 7.x MongoLockProvider to boot and lock against the emulator.
- Previously unsupported multi-node numeric write concern, unacknowledged write concern and replica-set tag modes now fail loudly under driver.writeConcernMultiNode, driver.writeConcernUnacknowledged and driver.writeConcernTag. The literal majority write concern remains supported.
Fixed
- findOneAndUpdate and findOneAndReplace now surface malformed operands and runtime update errors as MongoCommandException, completing the findAndModify command-family fix begun with duplicate keys; update-command writes retain MongoDB's write-error family. Pinned by m31-fau scenarios.
- A findOneAndUpdate or findOneAndReplace upsert that collides with an existing id now raises MongoCommandException code 11000 with codeName DuplicateKey, matching MongoDB's findAndModify command channel instead of the write-path MongoWriteException family. Update-command upserts retain the write-error family that MongoDB reports.
- The complete concern, preference and duplicate-key surface is pinned by new m26 differential scenarios. The lane now runs 654 scenarios against real MongoDB with zero divergences, plus a ShedLock end-to-end shim and passthrough test pair.