-
Notifications
You must be signed in to change notification settings - Fork 3
Description
Summary
The If-Overwritten-Version header documented in the RERUM API is not being enforced by TinyNode's /overwrite endpoint. Requests succeed even when the version in the header doesn't match the current server version.
Expected Behavior
According to the RERUM API documentation:
Including the 'If-Overwritten-Version' header with the value of the
__rerum.isOverwrittenproperty of the record will cause the request to fail if the record has been overwritten since that time.
When a client sends an /overwrite request with an If-Overwritten-Version header that doesn't match the current __rerum.isOverwritten value on the server, the server should return 409 Conflict.
Actual Behavior
The request succeeds with 200 OK and the object is overwritten, even when the If-Overwritten-Version header contains an outdated timestamp.
Steps to Reproduce
- Load an object and note its
__rerum.isOverwrittenvalue (e.g.,2025-11-30T20:31:57.853) - Update the object via
/overwrite- this changesisOverwrittento a new value (e.g.,2025-11-30T20:33:58.609) - Send another
/overwriterequest with headerIf-Overwritten-Version: 2025-11-30T20:31:57.853(the old value) - Expected: 409 Conflict response
- Actual: 200 OK, object is overwritten
Evidence
Request headers sent (verified in browser DevTools):
if-overwritten-version: 2025-11-30T20:31:57.853
content-type: application/json
Server's current isOverwritten at time of request: 2025-11-30T20:33:58.609
Response: 200 OK (should have been 409 Conflict)
Use Case
This feature is needed to implement optimistic locking for concurrent editing. Without server-side enforcement, two users editing the same object can silently overwrite each other's changes.
Related
- RERUM server issue: If-Overwritten-Version header not enforced when accessed via TinyNode rerum_server_nodejs#230
- RERUM API docs: https://store.rerum.io/v1/API.html#overwrite