Suspend, reinstate, revoke or delete a membership
What It Does
The workflow separates database authority from provider synchronization. Revocation and deletion persist queue work atomically with membership changes; suspension and reinstatement issue one provider call after commit.
The Flow
The diagram separates the relevant success, alternative and failure paths. The numbered hop rows retain the detailed authority checks, delegated work and retry limits.
When Something Fails
Fresh authorization observes membership changes. Cached decisions and signed contexts can lag within their expiry bounds, and provider removal can require dead-letter redrive. The console’s successful action message is not evidence that provider synchronization succeeded.
Repeated revocation retains its first timestamp. Removal work identifies pool and username; provider not-found is successful absence. Replayed consumer work converges, though a crash after provider success and before acknowledgement can repeat history. Dispatcher claims lapse for work not accepted by the queue.
Membership changes transact with related records and applicable lockout guards. Durable removal rows are written for revocation/deletion and dispatched across membership boundaries; suspension/reinstatement remain separate post-commit single attempts.
Open Design Questions
The recorded findings retain any stronger planning expectation, missing writer or unproved recovery path. Observed behavior does not approve those outstanding product choices.