[temisan0x]

Closes #936

What was broken

handleRevokeSingle and handleRevokeAll awaited the revoke callbacks with no error handling. If the request failed, the dialog stayed stuck on "Revoking..." forever and the rejection went unhandled, so the user couldn't retry and had no idea the session was still active.

What this changes

• Both handlers now use try/catch/finally, and the pending flags are cleared in finally.
• On failure, the session stays in the list. A session is only removed after the server confirms the revoke.
• The dialog stays open with an inline error, and the confirm button becomes Retry.
• The failure is announced through the existing live region.
• A second submit is blocked while one is in flight. Escape and overlay clicks are also ignored while a revoke is pending, so a late failure can't land on a dialog that has already closed.
• Cancel clears the error.
• Added a small .sm-dialog-error style for the inline message.

Tests

New SessionManagement.test.tsx covers:

• a rejected single revoke keeps the session, shows the error and clears the spinner
• Retry succeeds after a failed single revoke
• a rejected revoke-all keeps the sessions
• dismissing the dialog mid-request is ignored, and the error still shows
• both success paths still work

The failure-path tests fail on current master and pass with this fix.

One thing I noticed (not changed)

On a successful revoke-all, setSessions((prev) => prev.filter((s) => !s.isCurrent)) removes the current session from the list instead of the others. That looks backwards, but it's outside this issue's scope, so I left it alone.

[drips-wave]

@temisan0x Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits