[koniz-dev]

The session guards in AuthRepositoryImpl.refreshToken() and AuthInterceptor check the session immediately before a token write. That only works if a logout's clear, issued after the check, also lands after the write. On web, flutter_secure_storage 2.1.1 awaits WebCrypto encryption before localStorage.setItem, but delete/deleteAll call removeItem at once. So the clear landed first, and the write then re-stored a live access token on a signed-out browser. AuthInterceptor.onRequest would attach that token to the next request.

Change. SecureTokenStore runs every read, write and delete behind the operations issued before it, through a small queue that a failure does not wedge. Both logout paths share the one store through tokenStoreProvider: AuthRepositoryImpl.logout() and AuthInterceptor._logoutUser(), which both call clearAllTokens(). So the order the guards rely on now holds on every platform. Nothing clears on a stale return, so a session that started meanwhile keeps its tokens. The comment in refreshToken() now describes the store guarantee instead of an open window.

Tests. test/core/storage/adapters/secure_token_store_order_test.dart runs over a storage that reorders like the web plugin: writes land after an async step, deletes land at once.

• A clearAllTokens() issued after a pending setAccessToken() leaves nothing. This is the property _logoutUser() relies on.
• logout() during refreshToken()'s access-token write leaves both tokens null, and the refresh reports SESSION_TERMINATED.
• login() completing after the stale write keeps login-access / login-refresh.

Against the unqueued store, the first two fail.

Not verified (tier 3). Real WebCrypto timing in a browser.

Pre-merge review (a fresh qa subagent on the diff): no blocking defect. It found no re-entrancy, and errors propagate without wedging the queue. The queue is null while idle, as the cache's index queue is. Its points:

• AC2. It is covered at the store level: _logoutUser() only calls clearAllTokens() on the shared store, and the first test is exactly that ordering. No interceptor-level test is added.
• The guarantee was only on the implementation. It is now stated on ITokenStore (second commit).
• A hung platform call now holds every later token operation. This is documented on the class and filed as fix(storage): one hung secure-storage call now blocks every later token operation, including each request's token read and logout's clear #1002 (P2), since a plain timeout would reopen the reordering.
• SecureStorageService.clear() bypasses the queue. No caller is on the token path; filed as fix(storage): SecureStorageService.clear() bypasses the token store's ordering, so a logout built on it would reopen the web token race #1003 (P3).

Refs #986

🤖 Generated with Claude Code