Feature: Add Atomic Compare-and-Swap (CAS) API Endpoint
Description
Implement an atomic compare-and-swap (CAS) operation for the KV API to enable optimistic concurrency control. This would allow clients to update a key only if its current value matches an expected value (e.g., based on UUID or timestamp), reducing race conditions in distributed writes.
Motivation
KVS is eventually consistent with sophisticated conflict resolution (oldest-node rule + UUID tie-breaker), but lacks client-side atomicity for high-contention scenarios. CAS would provide a building block for safer updates without full transactions, aligning with the "local-first" philosophy while improving reliability for apps needing conditional writes.
Implementation Notes
Local Atomicity: Use BadgerDB's transactions for single-node CAS (check + set in one Update txn).
Distributed Handling: On success, trigger normal replication via Merkle sync. On failure, return immediately (no cross-node coordination needed for base impl).
Edge Cases: Handle TTL/compression integration; optional expected field for timestamp-only checks.
Config Toggle: Add cas_enabled: true to Config for opt-in.
Related
Ties into revision history (revision_history_enabled).
Test with integration_test.sh by simulating concurrent CAS attempts.
Feature: Add Atomic Compare-and-Swap (CAS) API Endpoint
Description
Implement an atomic compare-and-swap (CAS) operation for the KV API to enable optimistic concurrency control. This would allow clients to update a key only if its current value matches an expected value (e.g., based on UUID or timestamp), reducing race conditions in distributed writes.
Motivation
KVS is eventually consistent with sophisticated conflict resolution (oldest-node rule + UUID tie-breaker), but lacks client-side atomicity for high-contention scenarios. CAS would provide a building block for safer updates without full transactions, aligning with the "local-first" philosophy while improving reliability for apps needing conditional writes.
Implementation Notes
Local Atomicity: Use BadgerDB's transactions for single-node CAS (check + set in one Update txn).
Distributed Handling: On success, trigger normal replication via Merkle sync. On failure, return immediately (no cross-node coordination needed for base impl).
Edge Cases: Handle TTL/compression integration; optional expected field for timestamp-only checks.
Config Toggle: Add cas_enabled: true to Config for opt-in.
Related
Ties into revision history (revision_history_enabled).
Test with integration_test.sh by simulating concurrent CAS attempts.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Feature: Add Atomic Compare-and-Swap (CAS) API Endpoint
Description
Implement an atomic compare-and-swap (CAS) operation for the KV API to enable optimistic concurrency control. This would allow clients to update a key only if its current value matches an expected value (e.g., based on UUID or timestamp), reducing race conditions in distributed writes.
Motivation
KVS is eventually consistent with sophisticated conflict resolution (oldest-node rule + UUID tie-breaker), but lacks client-side atomicity for high-contention scenarios. CAS would provide a building block for safer updates without full transactions, aligning with the "local-first" philosophy while improving reliability for apps needing conditional writes.
Implementation Notes
Local Atomicity: Use BadgerDB's transactions for single-node CAS (check + set in one Update txn).
Distributed Handling: On success, trigger normal replication via Merkle sync. On failure, return immediately (no cross-node coordination needed for base impl).
Edge Cases: Handle TTL/compression integration; optional expected field for timestamp-only checks.
Config Toggle: Add cas_enabled: true to Config for opt-in.
Related
Ties into revision history (revision_history_enabled).
Test with integration_test.sh by simulating concurrent CAS attempts.