fix(mcp-store): fix MCP connect button loading state#2917
Open
cvolzer3 wants to merge 4 commits into
Open
Conversation
|
React Doctor found no issues in the changed files. 🎉 Reviewed by React Doctor for commit |
Contributor
|
Reviews (1): Last reviewed commit: "fix(ui): reset MCP connect loading state" | Re-trigger Greptile |
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.
Problem
MCP server connection failures could leave the Connect button stuck in a loading state. Reconnecting an OAuth MCP server also hit the browser redirect boundary: the MCP Store
authorizeendpoint redirects to the provider, but browser fetch cannot expose a cross-originLocationheader, which produced the status0failure.Reconnect can also be blocked by a transient PostHog token-refresh 500 if the app preemptively refreshes a still-valid in-memory access token.
Changes
redirect_urlfor PostHog Code instead of trying to inspect a manual browser redirect.Backend companion PR: PostHog/posthog#65917
How did you test this?
I did not do a manual app walkthrough. I ran:
pnpm --dir packages/ui exec vitest run src/features/mcp-servers/hooks/useMcpServers.test.tsxpnpm --filter @posthog/api-client test -- src/fetcher.test.ts src/posthog-client.test.tspnpm --filter @posthog/api-client typecheckpnpm --filter @posthog/ui typecheckpnpm --filter @posthog/core test -- src/auth/auth.test.tspnpm --filter @posthog/core typecheckpnpm exec biome lint packages/corepnpm exec biome check --write packages/ui/src/features/mcp-servers/hooks/useMcpServers.ts packages/ui/src/features/mcp-servers/hooks/useMcpServers.test.tsxpnpm exec biome check --write packages/api-client/src/fetcher.ts packages/api-client/src/posthog-client.ts packages/api-client/src/fetcher.test.ts packages/api-client/src/posthog-client.test.tsgit diff --checkThe pre-commit hook also ran
pnpm typecheckbefore the latest Code commits.Automatic notifications