fix(oauth): de-duplicate deep-link handling + quiet status-poll log - #189
Merged
Conversation
On a warm launch the OAuth approval deep link (mcpmux://authorize?request_id=…) is delivered twice — once by the deep-link plugin's on_open_url and again by the single-instance callback — so the whole consent flow ran twice per approval (duplicate consent emit + two get_pending_consent calls, visible in logs as back-to-back "[OAuth] Fetching pending consent"). - Drop a repeat of the same deep-link URL within a 3s window (`deep_link_is_duplicate`, gated by the pure, unit-tested `is_recent_duplicate_link`). Distinct authorizations carry a fresh request_id, so legitimate back-to-back flows are never collapsed. - Lower the per-call `get_gateway_status` log from INFO to DEBUG: the UI polls it on a timer and on every domain event, flooding the log (several lines/sec) and burying the events that matter. Note: this does not change the post-approval latency. Server-side, approval → code → token are all sub-millisecond; the redirect to a `cursor://` URL is handed to the OS via ShellExecuteW (returns in ~0.5s) and the remaining delay is the Windows shell routing the custom scheme + the client's own callback handling — outside the gateway. Claude-Session: https://claude.ai/code/session_01Baan9JmzR43uxxRUh7CAMF Signed-off-by: Mohammod Al Amin Ashik <maa.ashik00@gmail.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.
From investigating a report that OAuth approval felt slow / status was slow to update.
What was actually wrong (and fixed)
Deep link processed twice per approval. On a warm launch the approval deep link (
mcpmux://authorize?request_id=…) is delivered by both the deep-link plugin'son_open_urland the single-instance callback, so the consent flow ran twice — twoget_pending_consentcalls and a duplicate consent emit per approval (visible in logs as back-to-back[OAuth] Fetching pending consent).handle_deep_linknow drops a repeat of the same URL within a 3s window (deep_link_is_duplicate, backed by the pure, unit-testedis_recent_duplicate_link). Distinct authorizations carry a freshrequest_id, so legitimate back-to-back flows are never collapsed. 4 unit tests.Status-poll log spam. The UI polls
get_gateway_statuson a timer and on every domain event; at INFO it floods the log (several lines/sec) and buries real events. Lowered to DEBUG.What this does NOT fix (and why)
The post-approval 5–30s delay you saw is not in the gateway. Traced against the log: approval → code → token are all sub-millisecond server-side; the redirect to the client's
cursor://URL is handed to the OS viaShellExecuteW(returns in ~0.5s). The remaining time is the Windows shell routing thecursor://custom scheme + Cursor's own callback handling/timeout-retry — outside mcpmux. The code is bound to thecursor://redirect_uri Cursor itself requested, so the gateway can't reroute it. Also confirmed: the roots fetch runs in a spawned task (never blocks the handshake; succeeded onattempts=1), so the "root report delay" is not a factor.Follow-up (not in this PR): the frontend status polling is multi-caller and event-driven; consolidating those callers would cut call volume, but it's a separate frontend refactor.
https://claude.ai/code/session_01Baan9JmzR43uxxRUh7CAMF