Repository navigation
fix: keep the credential when a token refresh fails for want of a connection - #162
Merged
Merged
Conversation
…nection _performCheckAuthentication caught every refresh failure alike and fell through to authenticate(). A rejected credential (OpenIdException) is the one case where that is right. A refresh that fails because there is no connection — SocketException, timeout, a 5xx from the token endpoint — says nothing about the session, yet it sent the user to a login page they could not load, over an app that could have answered from its cache. Now only OpenIdException clears the credential and leads to the login. Any other failure keeps the credential for the next attempt and propagates out of checkAuthentication, where callers treat it like any other connectivity failure. performSetup completes in both cases, so isAuthenticated never hangs on a failed silent restore. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
ApptiveGridAuthenticator._performCheckAuthenticationrefreshes a saved token when none is in memory (cold start) or the current one is about to expire. It caught every refresh failure alike and fell through toauthenticate():OpenIdException) → login. Right.In Apptive Teams this is the craftsman in the basement: everything is cached, the refresh fails on the dead link, and the app opens a login page that cannot load. Mid-session it opens the login browser over a half-filled form, minutes after the read that triggered it was already answered from the cache.
Fix
OpenIdExceptionclears the credential and leads toauthenticate().checkAuthentication. Callers (getMe, the 401 retry inperformApptiveLink, the attachment processor) already handle connectivity errors; an offline-aware client can answer from its cache.performSetupwraps the silent restore in try/finally, so_setupCompletercompletes andisAuthenticatednever hangs on a failed restore.Version bumped to 2.3.1 with a CHANGELOG entry.
Tests
checkAuthenticationthrows,authorizenever called,saveCredential(null)never called.isAuthenticatedWithTokenresolves tofalse, no login, credential kept.flutter test --coverage: all passed, 0 uncovered lines.dart format --set-exit-if-changed,dart analyze --fatal-infosclean.flutter pub publish --dry-runonly warns about the (then) uncommitted files.Behaviour change for consumers
checkAuthentication()can now throw where it used to swallow and open the login. Apps that await it directly should expect connectivity errors; the ApptiveGrid client's own callers already propagate them.🤖 Generated with Claude Code