Every DataHub surface, and what it did here

The eight parts

Five things that were not in the documentation

Each of these was found by running against a real instance, and each fails silently, which is the reason they are worth writing down. A loud failure teaches you something the first time. These teach you nothing until much later.

• The MCP server stalls before the handshake It posts a usage ping before answering initialize. Where that host is unreachable the send retries for about forty seconds, and because it happens before the handshake the client sees no error and no response. Setting DATAHUB_TELEMETRY_ENABLED=false fixes it.
• MCP responses are trimmed, and type is one of the casualties Search results over MCP omit the entity type to save context. Filtering on it works in process and matches nothing over MCP, with no error. Entity type has to come from the urn, which no transport can afford to trim.
• Ingest order changes what the graph contains The mlflow connector overwrites the postgres entity's schema with the training frame's columns, so postgres has to run after mlflow. The dbt source resolves select * against the schema DataHub already holds, so postgres also has to run before dbt. The order is postgres, dbt, mlflow, postgres.
• Incidents do not attach to an ML model DataHub v1.5 rejects an mlModel urn at the entity layer. Only datasets, jobs, flows, dashboards and charts carry the aspect. The feature table turned out to be the better home anyway, since that is where a fix goes.
• One table exists three times, and only one copy carries the tags dbt, Postgres and MLflow each hold their own entity for the same table, joined as siblings. Governance tags declared in dbt land on the dbt entity, and there are 14 of them on dim_person. Lineage traversal returns Postgres urns, which carry zero. So the obvious question, asked the obvious way, returns nothing and reads as all clear. Every check here resolves siblings and reads the union before it answers.

Four of the five went back to the project