Bug 2059169 - Allow CheckAuthorizationStatus from more states

[bendk]

Pull Request checklist

• Breaking changes: This PR follows our breaking change policy
  • This PR follows the breaking change policy:
    • This PR has no breaking API changes, or
    • There are corresponding PRs for our consumer applications that resolve the breaking changes and have been approved
• Quality: This PR builds and tests run cleanly
  • Note:
    • For changes that need extra cross-platform testing, consider adding [ci full] to the PR title.
    • If this pull request includes a breaking change, consider cutting a new release after merging.
• Tests: This PR includes thorough tests or an explanation of why it does not
• Changelog: This PR includes a changelog entry in CHANGELOG.md or an explanation of why it does not need one
  • Any breaking changes to Swift or Kotlin binding APIs are noted explicitly
• Dependencies: This PR follows our dependency management guidelines
  • Any new dependencies are accompanied by a summary of the due diligence applied in selecting them.

[skhamis]

Nice!

[mhammond]

What's the motivation here? Do we ever expect AuthIssues to magically resolve itself? And shouldn't someone trying to check the auth status when, eg, Disconnected make more noise as it seems to strongly imply a confused client? ie, I don't think this is "wrong", but not sure it's "helpful" or something :)

[mhammond]

Do we ever expect AuthIssues to magically resolve itself?

ie, if it ever did resolve itself, it implies there was a bug which caused us to get into AuthIssues in the first place?

[mhammond]

oops, I see the info in the bug. It's a little sad, but I think this is fine.

[bendk]

What's the motivation here? Do we ever expect AuthIssues to magically resolve itself?

Not really. Should it be a no-op as well?

oops, I see the info in the bug. It's a little sad, but I think this is fine.

Agreed. It's kind of weird but I don't think the current Android behavior is too unreasonable.

[mhammond]

Not really. Should it be a no-op as well?

This seems fine I guess. I'd like to better understand the Android weirdness (but not enough to actually dig into it :) but given it exists, this isn't going to hurt.

[mhammond]

just noticed we do record some telemetry here - "Account Manager recovered a broken FxA auth state, without direct user involvement.". It would be interesting to see that - I don't think it would have great UX

[bendk]

just noticed we do record some telemetry here - "Account Manager recovered a broken FxA auth state, without direct user involvement.". It would be interesting to see that - I don't think it would have great UX

Oh. Given that the defined that telemetry, I'm going to keep the check from the AuthIssues state. One scenario I could imagine is they see a 401 error for normal reasons, maybe they tried to use an expired auth token or something, then the first auth check fails with a network error so they move to AuthIssues. At some point later they do another auth check and it works.

I'd like to better understand the Android weirdness

Other than the above weirdness, the other part is here. Whenever they see an auth error, they queue an operation that ends with sending us CheckAuthorizationStatus. Sometimes they see multiple auth errors at once, queue a bunch of those events, then the ones after the first can lead to the invalid state transition error.