fix(auth): stop double deep-link delivery wiping auth on macOS Tahoe#1895
Merged
richiemcilroy merged 1 commit intoJun 7, 2026
Merged
Conversation
Contributor
Author
|
@richiemcilroy that was lightning fast mate |
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
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.
Summary
On macOS Tahoe, the OS delivers the OAuth callback twice. When the deep-link wins the race, the local server stayed alive for 10s, the second delivery raced with
updateAuthPlanand wiped the auth store, looping back to login.Changes
auth.ts— dispose both listeners immediately when either wins the racelib.rs— stopupdate_auth_planfrom clearing auth on plan fetch failureTest plan
Greptile Summary
Fixes a macOS Tahoe bug where the OS delivers the OAuth deep-link callback twice: the first delivery set the auth store, but the 10-second delayed disposal of the local OAuth listener let the second delivery race with
updateAuthPlanand clear the auth, looping users back to login.auth.ts: Both the deep-link and local-callback listeners are now disposed immediately once either one wins thePromise.race, so a second OS delivery has nowhere to land.lib.rs: Removes theAuthStore::set(None)that was called wheneverAuthStore::getreturnedErrorOk(None)incheck_upgraded_and_update; the function now just returnsOk(false), preserving any valid auth already in the store.Confidence Score: 4/5
Both changes are targeted and correct; the only leftover is a dead source field in the race wrapper that is cosmetic.
The auth race fix correctly disposes both listeners immediately, and the Rust change removes the destructive store-clear on a transient auth-read failure. The source wrapper object left over in the TypeScript race is dead code but has no runtime impact.
No files require special attention beyond the minor dead-code cleanup in auth.ts.
Important Files Changed
Comments Outside Diff (1)
apps/desktop/src/utils/auth.ts, line 86-95 (link)sourcefield after the race simplificationThe
source: "deep-link" | "local"wrapper is now unused — the only consumer was theif (result.source === "deep-link")branch that this PR removed. ThePromise.racecan be simplified to resolve directly toAuthParams | null(i.e.await Promise.race([deepLink.complete, localCallback.complete])), andresult.databecomes justresult.Prompt To Fix With AI
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
Prompt To Fix All With AI
Reviews (1): Last reviewed commit: "fix(auth): stop double deep-link deliver..." | Re-trigger Greptile