Repository navigation
fix(connectors): stop the MCP OAuth wait when the user cancels sign-in - #3055
Conversation
|
@Asymtode712 is attempting to deploy a commit to the DocsGPT OSS Program Team on Vercel. A member of the Team first needs to authorize it. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to No actionable merge-blocking issue is established; the change is ready for normal merge checks. Pre-merge checks |
|
|
A maintainer will review this; the remaining workflow runs need maintainer approval. Automated triage. A maintainer will follow up. |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3055 +/- ##
==========================================
+ Coverage 91.27% 91.31% +0.04%
==========================================
Files 598 598
Lines 71565 71761 +196
==========================================
+ Hits 65318 65528 +210
+ Misses 6247 6233 -14 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Bug fix.
Why was this change needed? (You can also link to an open issue here)
Closes 🐛 Bug Report: Cancelling an MCP OAuth sign-in leaves the worker waiting, so the next sign-in shows a blank popup #3051
Cancelling an MCP OAuth sign-in only reset the frontend. The worker kept waiting up to 5 minutes for a callback that would never come. On the solo pool (
docsgpt workeron macOS and Windows), each cancelled attempt blocked the next sign-in, and its popup stayed blank.Fixing that exposed a second bug. The worker caches MCP clients for 5 minutes, keyed by server, transport and user, but not by sign-in attempt. A sign-in's client carries its task id and the publisher for that task's events, so a retry within 5 minutes reused the previous attempt's client. It published
mcp.oauth.awaiting_redirectunder the old task id, and the new popup, listening for its own task, stayed blank.Changes:
POST /api/mcp_server/oauth_cancel(task_id)./mcp_server/testrecords who started each sign-in, and only that user can cancel it; anyone else gets a 404. Cancelling sets a per-task mark in Redis.DocsGPTOAuthstops on it:callback_handlerchecks it on every 1-second poll, andredirect_handlerstops a sign-in cancelled while queued before it publishes the provider URL. The route has a PAT rule (tools:write, as for/mcp_server/test), anddocs/data/swagger.jsonis regenerated.MCPTool._setup_clientno longer caches or reuses a client built for a sign-in task (oauthauth, anoauth_task_id, not query mode). Other clients are cached as before.useMcpOAuthcalls the endpoint on the wizard's Cancel, when the user starts again, and when a cancel happened while/mcp_server/testwas still answering. It still ignorespopup.closed, because a provider's Cross-Origin-Opener-Policy (Stripe, Sentry) makes an active sign-in look closed. Leaving the page doesn't cancel; that attempt still ends on the 5-minute timeout./mcp_server/testis in flight, starting again, ownership checks, both handlers stopping on cancel, the route, and clients without a sign-in task still being shared.Demo:
Screen.Recording.2026-10-10.at.4.23.02.PM.mov
Other information:
soft_time_limitisn't enforced on the solo pool, so before this fix only the 5-minute poll ended an abandoned sign-in. It still does when the cancel request fails (it is best-effort) or when the user leaves the page.redirect_handler.ruff check .andnpm run lint(0 errors) pass, andnpm run buildsucceeds. The frontend connector and locale tests pass, and so dotests/agents,tests/api,tests/connectorsandtests/worker, excepttest_base_routes.py::TestCompleteStreamWalAcceptance::test_sources_found_before_the_pause_are_saved_with_it, which fails the same way onmain.Summary by CodeRabbit