[VibeSWE]

Summary

Follow-up from the #67 review (pre-existing, Medium): role syncs from the Query node to ingestors could be applied out of order.

• querier_role::put commits the role to object storage, releases UPDATE_LOCK, then fans the sync out in parallel.
• The ingestor receiver (ingestor_role::put) laid the request body over the stored metadata and installed the body, with no serialisation of its own.
• So two quick PUTs, A then B, could leave an ingestor running A.

Fix (receiver only, no wire-format change): the ingestor now:

1. takes its own UPDATE_LOCK;
2. re-reads the tenant's metadata from storage;
3. installs the stored role, or removes it from the live map if storage no longer has it;
4. refreshes affected sessions, then writes staging as before.

The querier commits to storage before sending any sync, and each receiver reads and installs under the lock. So whichever sync an ingestor processes last reflects the latest write, and a late PUT sync can no longer bring back a deleted role.

Mixed versions: SyncRole and the route are unchanged. The body's tenant_id is still used; its privileges are now ignored.

A failed staging write after a sync is now logged as a warning instead of being dropped with let _.

Tests

The install step is factored into a helper. The handler path needs storage, which the test binary can't initialise. Two tests, committed red first:

• a stale body doesn't override the stored role;
• a sync for a role storage no longer has removes the live role.

Verification

• cargo fmt --check ✅, cargo clippy -- -D warnings ✅
• cargo test --lib: 1023 passed, 0 failed, 2 ignored

Not in this PR

• Role DELETE never reaches ingestors: the receiver route DELETE /role/{name}/sync is commented out in ingest_server.rs (since upstream 91debc3a), so deleted roles stay live on ingestors until restart. Restoring it changes the ingestor's exposed routes, so it's left for a separate decision.
• Failed syncs are only logged: an ingestor that misses one stays stale until the next sync of that role, or a restart.
• Querier role DELETE locking: fixed in Take UPDATE_LOCK in querier role DELETE and before password resets #77.

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}

[VibeSWE]

Adversarial review of PR #78 (at a196fc34, fixes in fff61ed5)

One Sol 6.1 and one Opus 5.5 reviewer. Neither found anything blocking.

Both confirmed:

• Commit before send: the querier commits to remote storage before sending the sync.
• Reads are fresh: get_metadata reads object storage directly, with no staging fallback or cache.
• Locks: no lock inversion, no parking_lot guard held across .await, and nothing re-enters UPDATE_LOCK.
• HTTP contract and mixed versions: both unchanged. No ingestor error can fail the user's PUT, before or after this PR.
• Nothing else depends on the body: no bootstrap, migration or test path relies on the request body being installed.

Severity	Finding	Outcome
Low	stale_sync_body_does_not_override_stored_role no longer tested an overwrite after the helper stopped taking a body	Renamed to installs_stored_role_over_live_role; it now seeds live A first
Low	Session removal was untested	New test: direct holders and group members lose their sessions; unrelated users and other tenants keep theirs
Low	A sync naming an internal role (e.g. super-admin, which is never in storage) would now remove it	Fixed: internal live roles are left alone. Red test first
Low	Convergence assumes read-after-write-consistent storage and delivery of the latest sync	Documented. Failed syncs are still only logged (see the PR body)
Nit	The ingestor holds UPDATE_LOCK across one storage GET	Kept: ingestor_rbac.rs already does the same

Separate High (pre-existing) found during review: role removals from users never apply on ingestors. The receiver validates against remote metadata the querier has already updated. A fix is in progress on its own branch.

Local at fff61ed5: fmt and clippy -- -D warnings clean; cargo test --lib 1025 passed, 0 failed.