Closed Bug 2036792 Opened 6 months ago Closed 5 months ago

FxA Oauth Token destruction is racy.

Categories

(Firefox :: IP Protection, defect)

defect

Tracking

()

VERIFIED FIXED
152 Branch
Tracking Status
firefox-esr140 --- unaffected
firefox150 --- unaffected
firefox151 --- unaffected
firefox152 --- verified

People

(Reporter: sstreich, Assigned: sstreich)

References

(Regression)

Details

(Keywords: regression, Whiteboard: [fx-vpn])

Attachments

(1 external file)

The changes in 2034525 allowed the option for the destroy path to be called before the /token request has concluded, this caused a flaky race situation.

Assignee: nobody → sstreich
Whiteboard: [fx-vpn]

Set release status flags based on info from the regressing bug 2034525

If we don't await the call to guardian client but instantly return the promise, the FxA token destroy request will be sent while request to guardian is mid-flight.

Do you think that bug 2036612 might be related?

Pushed by sstreich@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/3efa4fcefd25 https://hg.mozilla.org/integration/autoland/rev/b4d3fe5dc9e9 make sure requests have concluded before desposing the token r=ip-protection-reviewers,fchasen,kpatenio
Duplicate of this bug: 2036612
Status: NEW → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → 152 Branch

We have verified this using Firefox Nightly 152.0a1 (2026-05-05) build on Windows 11.
The VPN can e turned on. Is there something else that QA can verify here? Thank you!

Flags: needinfo?(sstreich)
QA Whiteboard: [qa-triage-done-c153/b152]

Nothing else to do thanks!

Flags: needinfo?(sstreich)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: