Persist state machine's state
Categories
(Fenix :: Accounts and Sync, task)
Tracking
(Not tracked)
People
(Reporter: jonalmeida, Unassigned)
References
(Blocks 1 open bug)
Details
From github: https://github.com/mozilla-mobile/android-components/issues/5102.
Our account state machine's state is currently derived from scratch upon initialization, based on the state of our persisted account, and how the interaction with the server goes.
This has been mostly fine so far, but if the state is persisted, we can short-circuit into
AuthenticationProblem
state and prevent us from hitting the servers when we know for certain our interaction will result in 401 errors.This is a follow-up to https://github.com/mozilla-mobile/android-components/issues./5050#issuecomment-555296800.
To deal with a case when we fail to reliably determine if we can recover or not from our auth problems (that's #3347), we may need to consider another state here -
MaybeAuthenticationProblem
, perhaps. In which case, we can avoid short-circuiting and go through the full state machine, to essentially "try again" and see if we can recover.┆Issue is synchronized with this Jira Task
Change performed by the Move to Bugzilla add-on.
Updated•2 years ago
|
Comment 1•9 months ago
|
||
This is basically all setup, we just need to uncomment this code. The reason I haven't done it yet is that I want the state machine code to match the current android-components code in order for the checker to work.
Description
•