[GH-ISSUE #184] Avoid lost updates in project policy revoke due to read-modify-write race #132

New issue

Closed

opened 2026-10-15 18:21:26 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 18:21:26 +00:00

Owner

Originally created by @morluto on GitHub (Jul 14, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/184

Environment

Local repo: /root/rea
Commit: current workspace HEAD
Area: CLI policy commands

Current behavior

rea policy revoke <grant-id> reads the project permission store, filters out the target grant_id, and writes the filtered list back to disk.

Read: readProjectGrants in src/cliPolicyCommands.ts (through readProjectPermissionStore)
Write: writeProjectPermissionStore in the same flow

This is a read-modify-write sequence with no merge or conflict check.

Impact

If two policy revoke commands (or any process writing project grants) run concurrently, one invocation can clobber the other’s changes because both are based on stale snapshots. A revoke in one command can unintentionally keep or drop grants written by another command.

Repro scenario

Open two terminals in the same project.
In terminal A, run rea policy revoke <grant-id-1>.
In terminal B, run rea policy revoke <grant-id-2> at the same time.
Last write wins; one grant change may be lost depending on timing.

Suggested fix

Add a store mutation strategy that avoids lost updates, e.g.:
- re-read and re-apply change in a short retry loop, or
- file-level advisory locking, or
- include/store a version token and fail with a retryable conflict.
Keep owner-only mode check from readProjectPermissionStore/writeProjectPermissionStore intact.

Originally created by @morluto on GitHub (Jul 14, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/184 ## Environment - Local repo: `/root/rea` - Commit: current workspace HEAD - Area: CLI policy commands ## Current behavior `rea policy revoke <grant-id>` reads the project permission store, filters out the target `grant_id`, and writes the filtered list back to disk. - Read: `readProjectGrants` in `src/cliPolicyCommands.ts` (through `readProjectPermissionStore`) - Write: `writeProjectPermissionStore` in the same flow This is a read-modify-write sequence with no merge or conflict check. ## Impact If two `policy revoke` commands (or any process writing project grants) run concurrently, one invocation can clobber the other’s changes because both are based on stale snapshots. A revoke in one command can unintentionally keep or drop grants written by another command. ## Repro scenario 1. Open two terminals in the same project. 2. In terminal A, run `rea policy revoke <grant-id-1>`. 3. In terminal B, run `rea policy revoke <grant-id-2>` at the same time. 4. Last write wins; one grant change may be lost depending on timing. ## Suggested fix - Add a store mutation strategy that avoids lost updates, e.g.: - re-read and re-apply change in a short retry loop, or - file-level advisory locking, or - include/store a version token and fail with a retryable conflict. - Keep owner-only mode check from `readProjectPermissionStore`/`writeProjectPermissionStore` intact.

bsakaguchi

2026-10-15 18:21:26 +00:00

closed this issue
added the
area: cli

enhancement
labels

bsakaguchi added

enhancement

and removed

enhancement

labels

2026-10-31 00:28:45 +00:00

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#132

No description provided.

Rows
Columns