Environment
- Server version: current main (2389a9cab)
- Node.js version: v25.5.0
- npm version: 11.8.0
Description
LockingResourceStore renews expiring read locks as response data is consumed, but it does not renew write locks while an incoming representation is being consumed.
All standard configurations wrap the resource locker in a WrappedExpiringReadWriteLocker. A slow or stalled PUT/POST body can therefore outlive the lock expiration while the source store is still consuming it. The lock is released, but the first write continues, so a second writer can acquire the same lock and overlap with an unprotected write.
The write path should renew the lock whenever it reads from the incoming representation. If the held lock nevertheless expires mid-write, it should abort the incoming stream so the source store cannot continue writing without the lock.
This is separate from lock-acquisition contention: acquisition failures should leave the request stream intact so the server can return the error response cleanly.
Reactions are currently unavailable
Environment
Description
LockingResourceStore renews expiring read locks as response data is consumed, but it does not renew write locks while an incoming representation is being consumed.
All standard configurations wrap the resource locker in a WrappedExpiringReadWriteLocker. A slow or stalled PUT/POST body can therefore outlive the lock expiration while the source store is still consuming it. The lock is released, but the first write continues, so a second writer can acquire the same lock and overlap with an unprotected write.
The write path should renew the lock whenever it reads from the incoming representation. If the held lock nevertheless expires mid-write, it should abort the incoming stream so the source store cannot continue writing without the lock.
This is separate from lock-acquisition contention: acquisition failures should leave the request stream intact so the server can return the error response cleanly.