feat: extend workspace lock to CAC write entities - #1069
Conversation
|
Important Review skippedToo many files! This PR contains 207 files, which is 107 over the limit of 100. To get a review, narrow the scope: Upgrade to a paid plan to raise the limit. This review couldn't start because sufficient usage credits or metered capacity aren't available. Add credits or update usage-based reviews in the billing tab, then retry. ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (207)
You can disable this status message by setting the ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
e92a6ae to
e928bc1
Compare
e928bc1 to
8a3e57e
Compare
Problem
Concurrent write requests to the same workspace can cause conflicting updates and inconsistent state.
Solution
Add a workspace-level write permit backed by a database lease. Standard writes use the default TTL, bulk context updates use the batch TTL, and all TTLs have a 60-second minimum.
Environment variable changes
Optional configuration:
WORKSPACE_LOCK_DEFAULT_TTL_MS— defaults to60000.WORKSPACE_LOCK_BATCH_TTL_MS— defaults to1200000.Pre-deployment activity
Run the workspace-lock database migration before deploying the application.
Post-deployment activity
None.
API changes
POST/PUT/PATCH/DELETE409 Conflictwhen the workspace is lockedPossible Issues in the future
Operations exceeding their TTL may allow another writer to acquire the lock. Failed processes may leave a lock active until its TTL expires.