Server Runtime Lock Contract

ChannelLockManager serializes work that can otherwise execute protected handlers or settlement transitions concurrently. The in-memory implementation is for a single server process. Production deployments that run more than one server process for the same trust domain need a shared lock manager.

Required Guarantees

• runExclusive(key, fn) must run only one fn at a time for the same key.
• A failed fn must release the key.
• Different keys may run concurrently.
• Lock acquisition and release must be visible to every process that can accept the same payment, channel, or payment identifier.

Required Scopes

The direct-mode server uses the lock manager for:

• payment identifiers, keyed by the payment identifier extension id;
• batch channels, keyed by channel id;
• exact payments before verification, keyed by the payload's transaction hint or transaction bytes;
• exact payments after verification, keyed by the verifier-derived transaction id.

The post-verification exact lock is the handler-safety lock. Durable stores still need unique transaction-id replay records because locks can expire, fail, or be lost during process shutdown.

Source: /docs/server-runtime-lock-contract.md