Short answer: treat global logout as a reconciliation job. Snapshot every session, revoke from that inventory, then prove each identifier is rejected after revocation; a success banner is not evidence.
An edtech forgot-password flow makes this painfully concrete. A learner may have a browser, a phone, a shared family tablet, and a proctoring window open at once. Resetting the password without closing those sessions leaves the old bearer credentials useful. The security decision is session security versus friction: revoke everything for a high-risk reset, and make an ordinary password change less disruptive only when policy allows it.
I have been paged for missed jobs and duplicate deliveries, so I use the same operating rule here: an action is incomplete until its recorded result can be reconciled with an independent check.
The incident lesson: logout is a state transition, not a button
The failure mode is usually an inventory problem. The logout handler knows about the current cookie, while refresh tokens, mobile sessions, and older web sessions live in different stores. It returns 200, deletes one record, and the UI says “signed out.” The next request from a second device still succeeds. In a review, I draw the timeline on a whiteboard: the reset request arrives, the inventory cutoff is chosen, one database replica observes the revoke, a cache serves an older decision, and a phone presents a refresh token that was never in the browser table. Each hop needs an owner and a timestamp. The report must distinguish a token that was absent at cutoff from a token that was present and rejected. That distinction changes both incident response and what a reviewer can reproduce. We also keep the probe harness outside the normal learner path, because an audit check must not alter course progress, consume a one-time recovery code, or trigger a notification storm. A bounded queue gives operators a place to pause, resume, and inspect work without pretending that eventual completion happened immediately.
