basalt / drives/src / DriveRevocationOutcome

Type Alias: DriveRevocationOutcome

> DriveRevocationOutcome = "revoked" | "skipped" | "unsupported" | "failed"

What happened when disconnect tried to revoke the grant at the provider.

revoked: false used to be the whole answer, and it meant three different things an operator has to act on differently:

revoked — the provider accepted it. The grant is gone.
skipped — the caller asked for a local-only disconnect (revoke: false).
unsupported — the adapter has no revocation endpoint to call, and never will. Microsoft Graph is this: there is no per-application revoke, so the grant lives until the user removes it at myaccount.microsoft.com. Nothing an operator retries will change it.
failed — we asked and the provider did not answer: it was down, or the token was already dead. The grant may still be live, and unlike unsupported this is worth trying again.

Distinguishing the last two is the point. RFC 0002 §D.3.1 identified the ambiguity and left it documented rather than encoded, on the grounds that a third connection status would carry one vendor's absence into every adapter. That reasoning is sound and does not apply here: this is decided entirely by the engine, from facts it already has, and no adapter gains a member or changes a line. Meanwhile the guide's own example branched on the boolean to tell the user to go and withdraw consent by hand — the right advice for unsupported and the wrong advice for failed.