Description

Prior to CDS 10 the queue processed messages with legacy locking enabled by default, which serialized access to a message across concurrent consumers. CDS 10 changes the default to legacyLocking: false, meaning multiple consumers can now compete for the same message without the old serialization guarantee. Projects that depend on the serialized behavior must explicitly set legacyLocking: true to preserve it, but this opt-out will itself be removed in cds^11. The change affects all queue-backed messaging services unless the new locking behavior was already adopted.

How to Check

• [ ] Search cds env output for any key under cds.requires.messaging or a named queue config (e.g. cds.requires.my-queue) and verify whether legacyLocking is set.
• [ ] If legacyLocking is absent and the queue processes messages that must not be delivered to two consumers simultaneously, the new default is breaking.
• [ ] Review service handlers that consume from the queue for assumptions about exclusive message access or processing order under concurrent load.

Migration Steps

1. Audit queue configuration in package.json or .cdsrc.json and identify whether serialized locking is required for correctness.

2. If you need time to adapt consumers, temporarily set the compat flag to restore the CDS 9 serialized-locking behavior. Note: this option is removed in cds^11 and must not be left in place permanently:

    "cds": {
      "requires": {
        "messaging": {
   +      "legacyLocking": true
        }
      }
    }

3. Plan migration away from legacyLocking: true before upgrading to cds^11, where the option is removed entirely. Adapt consumers to be idempotent or use the new locking primitives where available.

Notes

The legacyLocking compat opt-out is a temporary bridge. It will not be available in cds^11. Any project that sets it must be updated before the next major upgrade.