Problem
Several React mutation handlers use effect-atom's mode: "promise" and return a rejected promise when the mutation fails. Their UI callers discard that promise, so the rejection does not produce user-visible feedback.
This affects two workflows:
Policy mutations
Policy create, update, and remove failures produce no error toast.
The policy clear path also deletes its locally tracked created-policy ID before the server confirms removal. If removal fails, the optimistic policy is restored, but the ID bookkeeping has already been lost.
OAuth app removal
A failed OAuth client removal closes the confirmation dialog before the request completes. The rejected promise prevents the success toast and selected-app cleanup from running, but no failure message is shown and the user must reopen the removal flow.
This does not produce a false success toast. The problem is the missing failure handling and premature dialog state change.
Expected behavior
- Failed mutations show the server or mutation error in the UI.
- Policy created-ID bookkeeping changes only after confirmed success.
- The OAuth removal dialog remains open when removal fails.
- Success analytics, notifications, and local state changes run only after confirmed success.
Regression evidence
Applying browser regression tests to the current base causes both scenarios to time out while waiting for the expected failure messages:
- Policy creation rejection:
Failed to create policy
- OAuth client removal rejection:
Failed to remove <app>
The policy clear test additionally verifies that a rejected removal leaves the policy blocked and persisted.
Problem
Several React mutation handlers use effect-atom's
mode: "promise"and return a rejected promise when the mutation fails. Their UI callers discard that promise, so the rejection does not produce user-visible feedback.This affects two workflows:
Policy mutations
Policy create, update, and remove failures produce no error toast.
The policy clear path also deletes its locally tracked created-policy ID before the server confirms removal. If removal fails, the optimistic policy is restored, but the ID bookkeeping has already been lost.
OAuth app removal
A failed OAuth client removal closes the confirmation dialog before the request completes. The rejected promise prevents the success toast and selected-app cleanup from running, but no failure message is shown and the user must reopen the removal flow.
This does not produce a false success toast. The problem is the missing failure handling and premature dialog state change.
Expected behavior
Regression evidence
Applying browser regression tests to the current base causes both scenarios to time out while waiting for the expected failure messages:
Failed to create policyFailed to remove <app>The policy clear test additionally verifies that a rejected removal leaves the policy blocked and persisted.