Repository navigation
docs(mcp): two self-hosted troubleshooting entries - #18684
cnpierrepapi wants to merge 1 commit into
Conversation
github-actions
Bot
added
docs
maggiehays
added
the
needs-review
|
Bumping this one, it has been sitting since 28 July with checks green and no reviewer. It is unrelated to the incidents work in #18685 and #18999, so it should not be waiting on any of that. Both entries are the same class of problem: the self-hosted stdio server fails in a way that produces no error. The first is the startup usage ping. It goes out before the MCP handshake completes, so on a host that cannot reach The second is Both cost me an afternoon each, and neither leaves anything to search for, which is why I wrote them up rather than just fixing my own setup. @AdrianMachado you have been reviewing my other docs PR, so you may know who owns this page. Happy to split it into two entries if either half is contentious. |
I will try and find an owner to review |
maggiehays
added
pending-submitter-response
Two entries for the self-hosted troubleshooting section, both hit while running
mcp-server-datahubagainst a self-hosted DataHub Core instance (GMS v1.5.0.6,server
datahub 3.4.5) on an EC2 host with restricted egress.Both fail silently, which is why they seemed worth writing down. Neither
produces an error a client can surface.
1. The server never answers
initialize.The startup usage ping to
track.datahubproject.iois sent before the MCPhandshake completes. On a host that cannot reach it, urllib3 retries four times
at a ten second connect timeout, and because this happens before the protocol
starts the client has nothing to report and just waits. My first session looked
like a hang with no output at all; it took running the server by hand and
reading stderr to see the retries.
This is not exotic: it is the default state of an air-gapped host, and of any
cloud instance whose egress rules allow the GMS endpoint but not general
outbound HTTPS.
The fix is
DATAHUB_TELEMETRY_ENABLED=false, which is documented for the CLIbut easy to miss here, since nothing about the symptom points at telemetry.
2.
typeis absent fromsearchresults over MCP.Responses are trimmed to fit a model's context window, and entity
typeis oneof the dropped fields. The same call through
datahub-agent-contextin processdoes return it. A client that filters search results by entity kind therefore
works against the SDK and matches nothing over MCP, with no error either way.
Suggesting the URN as the source instead, since it is the identifier and cannot
be trimmed.
Docs only, no code changes.