fix(professional-crm): two deploy-blocking bugs in the Edge Function reference#330
Open
UpLeafed wants to merge 2 commits into
Open
fix(professional-crm): two deploy-blocking bugs in the Edge Function reference#330UpLeafed wants to merge 2 commits into
UpLeafed wants to merge 2 commits into
Conversation
…d options The pinned @hono/mcp@0.1.1 (deno.json) does not accept the `sessionIdGenerator` or `enableJsonResponse` options on its StreamableHTTPTransport constructor. Passing them causes the request handler to fail at runtime, returning HTTP 500 on every POST to the Edge Function. The function appears reachable (GET probes return 200) but all MCP traffic fails, which manifests in Claude Desktop as "Couldn't reach the MCP server" or — once the connector retries — "Couldn't register with sign-in service" (Claude infers OAuth from the 500 response). Calling the constructor with no arguments matches the working pattern in other OB1 extensions and restores normal operation. Verified with manual MCP initialize + tools/list against a deployed Supabase Edge Function: HTTP 200, all 10 crm_* tools register and respond correctly.
…clients
Claude Desktop and claude.ai connectors send an OPTIONS preflight before
opening the MCP stream. Without an OPTIONS handler the function returns
404 on preflight and the connector reports either "Couldn't reach the
MCP server" or, after retry, "Couldn't register with sign-in service"
(Claude infers an OAuth flow from the missing preflight).
This mirrors the pattern already used in the core OpenBrain MCP server
example: an `app.options("*", ...)` handler that returns the CORS
headers, plus those same headers attached to the 401 / 500 error
responses and the GET status endpoint so the browser-based connector
can actually read the response body.
The success path through `transport.handleRequest(c)` is unchanged —
@hono/mcp emits its own response for the JSON-RPC body, which has been
empirically sufficient for browser-context MCP clients.
|
Hey @UpLeafed — welcome to Open Brain Source! 👋 Thanks for submitting your first PR. The automated review will run shortly and check things like metadata, folder structure, and README completeness. If anything needs fixing, the review comment will tell you exactly what. Once the automated checks pass, a human admin will review for quality and clarity. Expect a response within a few days. If you have questions, check out CONTRIBUTING.md or open an issue. |
This was referenced May 27, 2026
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
Fixes two issues that prevent
extensions/professional-crm/index.tsfrom being deployed as published — anyone who follows the README and runssupabase functions deploy professional-crm-mcpagainst a fresh project hits both immediately.Discovered while deploying the extension against a real Supabase project + claude.ai connector. Each fix is isolated in its own commit so they can be reviewed (or split into separate PRs) independently.
Bug 1 —
StreamableHTTPTransportconstructor options crash on every POSTThe transport is instantiated with
{ sessionIdGenerator: undefined, enableJsonResponse: true }. The pinned@hono/mcp@0.1.1(deno.json) does not accept these options on itsStreamableHTTPTransportconstructor — passing them causes the handler to fail at runtime, returning HTTP 500 on every POST. GET probes return 200 (looks healthy), but MCP traffic 100% fails.Symptom in Claude Desktop:
"Couldn't reach the MCP server"on first connect, then — after retry —"Couldn't register with sign-in service. You can try again, or add an OAuth Client ID in the connector settings"(Claude infers an OAuth flow from the 500 response).Fix:
new StreamableHTTPTransport()with no args, matching the pattern in OB1's working core MCP example.Bug 2 — Missing CORS preflight + response headers
Claude Desktop and claude.ai connectors send an OPTIONS preflight before opening the MCP stream. Without an
app.options(...)handler, Hono returns 404 and the connector probe fails. Error responses (401, 500) also need CORS headers so the browser-based client can read the JSON body.Fix: add
corsHeaders, anapp.options("*", ...)handler, and attachcorsHeadersto existing 401/500/GET responses. The MCP success path throughtransport.handleRequest(c)is unchanged.Verification
After applying both commits, deployed to a Supabase Edge Function (
@hono/mcp@0.1.1,@modelcontextprotocol/sdk@1.24.3, hono@4.9.2 — all per the pinned deno.json) and confirmed:OPTIONS /functions/v1/professional-crm-mcp→ 200 with CORS headersGET /functions/v1/professional-crm-mcp→ 200 status JSONPOST … {"method":"initialize"}→ 200 with proper MCPserverInfoPOST … {"method":"tools/list"}→ 200 listing all 10crm_*toolsPOST … {"method":"tools/call","params":{"name":"crm_get_follow_ups",…}}→ 200 with real data fromprofessional_contactsTest plan
mainagainst a clean Supabase project with the four required secrets setinitializereturns the expectedserverInfoJSONCloses #331