Skip to content

feat(key-browser): use optimistic locking with WATCH for key updates - #572

Open
RajGahoi wants to merge 2 commits into
valkey-io:mainfrom
RajGahoi:feat/key-browser-optimistic-locking-watch
Open

RajGahoi wants to merge 2 commits into
valkey-io:mainfrom
RajGahoi:feat/key-browser-optimistic-locking-watch

Conversation

@RajGahoi

Copy link
Copy Markdown
Contributor

Description

Fixes #533.

Previously, key modification functions in apps/server/src/keys-browser.ts (e.g. updateStringKey, updateJsonKey, updateHashKey, updateListKey, updateSetKey, and updateZSetKey) performed pre-write validation reads (such as checking GET for binary content) and non-transactional command sequences without optimistic concurrency control. If another client modified the key between the read and write operations, races and silent data overwrites could occur.

This pull request implements optimistic locking via Valkey's WATCH and atomic transactions (Batch / ClusterBatch):

  • Calls await client.watch([key]) prior to reading or building updates for string, json, hash, list, set, and zset keys.
  • Executes update and TTL commands inside an atomic batch (client.exec(batch, true)).
  • Automatically un-watches the key via client.unwatch() if validation fails or an exception occurs.
  • Detects null transaction responses (aborted due to concurrent modification) and surfaces an informative error: 'Key was modified by another client during edit (optimistic lock conflict).'.

Testing

  • Extended apps/server/src/__tests__/keys-browser.test.ts to verify that watch, atomic batch execution, and un-watch on abort operate as expected.
  • Verified optimistic lock conflict abort handling when concurrent edits occur.
  • Verified clean build and lint across frontend and server workspaces.

Fixes valkey-io#533. Previously, update functions in keys-browser.ts (e.g. updateStringKey, updateJsonKey, updateHashKey) performed read operations such as GET before issuing SET/SETEX without optimistic concurrency control, allowing write races if the key was updated concurrently. This commit wraps all update operations with client.watch([key]) and executes changes inside an atomic batch (Batch/ClusterBatch). If the watched key is modified concurrently, the transaction cleanly aborts and reports an optimistic lock conflict error.

Signed-off-by: Raj Gahoi <gahoiraj01@gmail.com>
@coderabbitai

coderabbitai Bot commented Oct 17, 2026 •

Copy link
Copy Markdown

Warning

Review limit reached

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Next included review available in 3 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used all 2 included reviews currently available.

Learn how review limits work.

Review configuration:

⚙️ Run configuration
  • Configuration used: Organization UI
  • Review profile: CHILL
  • Plan: Advanced
  • Run ID: 7aa0d3fe-3a3c-4220-b398-1c35efda8084
📥 Commits

Reviewing files that changed from the base of the PR and between 0161e2a and 0fe30bb.

📒 Files selected for processing: 2
  • apps/server/src/__tests__/keys-browser.test.ts
  • apps/server/src/keys-browser.ts
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@github-actions github-actions Bot added the area/server Backend, WebSocket, actions label Oct 17, 2026
Signed-off-by: Raj Gahoi <gahoiraj01@gmail.com>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/server Backend, WebSocket, actions

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Use optimistic locking using WATCH for multi part transactions

1 participant