Skip to main content

Lineage Troubleshooting

Use this guide to resolve common lineage issues in Catalog, including missing upstream lineage, truncated queries, temporary table conflicts, and timeout errors.

Source Query and Upstream Lineage Not Visible

Lineage is computed based on the last 30 days. Confirm that the asset has been refreshed during this period.

Source Query Visible but No Upstream Lineage

When you see a source query but no upstream lineage, work through the checks below.

Verify That Parent and Child Assets Are in Catalog

Catalog computes lineage between assets that are available in Catalog. Verify that Catalog has sufficient rights to extract missing metadata.

Multiple Layers of Temporary Tables

Catalog supports 2 levels of temporary tables by default. If you use more, reach out to your Catalog point of contact to request a higher limit.

Source Query Visible but Truncated

Catalog supports full visualization of queries that have up to 100,000 characters. When a query passes this limit, it is displayed with << TRUNCATED >> and only table-level upstream lineage is calculated.

Source Query of Temporary Table Shown for Materialized Table

To match a source query with its associated table, Catalog uses the path of the asset. If you have a temporary table with the exact same name and path as a materialized one, there will be a conflict.

Rename the temporary table so it has a unique name.

Looker-Specific Lineage Issues

These issues apply to Looker integrations specifically.

Cannot See Lineage for Looker Assets

Catalog computes lineage by analyzing your LookML. Confirm that Catalog has access to your LookML repo. See the Looker LookML access documentation for more information.

Lineage Disappears After a Database or Connection Change in LookML

You might see column to field lineage and table to dashboard lineage drop in bulk after you change LookML, a Looker connection, or base view targets so Explores resolve to a different warehouse database than before. The change usually shows up after the next successful Looker sync and lineage processing.

Catalog builds Looker lineage by combining LookML with warehouse metadata that is already in Catalog. Each Explore resolves to concrete warehouse coordinates: database, schema, and tables through the model and connection. Catalog matches lineage only where those names correspond to databases and tables your Warehouse integration has ingested. If Explores point at a database Catalog does not ingest, links that depended on the earlier match can disappear after extraction.

Use these practices to avoid the mismatch:

  • Coordinate ingestion with LookML changes - Before Explores reference a new database in production, include that database in your Warehouse integration scope, including credentials, allow lists, and any filters your team uses.
  • Align Git branches with what Catalog reads - If Catalog reads a development branch while production LookML points Explores at production only in another branch, ingestion scope and the branch Catalog indexes must still line up with the coordinates Explores expose.
  • Treat development and production as separate checks - If only a development database is ingested but LookML switches Explores to production, or the inverse, lineage can fail until both the LookML target and ingestion scope match.

To recover when lineage has already dropped:

  1. Identify which database and schema Looker resolves for the affected Explores. Use Looker model documentation or admin tools in your organization to confirm the mapping.
  2. Confirm your Warehouse integration ingests that database and that Settings > Integrations shows a healthy run for the Warehouse source.
  3. Update LookML or the Looker connection so Explores reference ingested databases, then merge or publish the branch Catalog reads for LookML if you use version control.
  4. Run a full Looker extraction and upload to Catalog using your normal Catalog-managed or client-managed workflow. See the Looker integration documentation for castor-upload and scheduling guidance.

To verify the fix:

  1. Wait for the Looker ingestion you triggered to finish.
  2. Open a sample Explore in Catalog and confirm column lineage and upstream dashboards look complete again.

If access and warehouse alignment look correct but lineage is still missing, review Cannot See Lineage for Looker Assets and Some Looker Assets Do Not Have Lineage in this guide.

Some Looker Assets Do Not Have Lineage

Catalog consistently improves the lineage engine with new scenarios. Here is a non-exhaustive list of scenarios not yet covered, with support coming soon:

  • {view_name.SQL_TABLE_NAME} pattern
  • Hidden fields used in calculated fields
  • Conditional lineage: Liquid
  • Native derived table
  • Refined explores

Power BI Field Lineage After Column Renames

When field lineage in Catalog looks wrong after you rename columns in Power BI Power Query, the limitation is often how M expresses renames, for example with Table.RenameColumns, rather than a generic upstream lineage gap. See Troubleshoot Power BI Lineage When Columns Are Renamed for supported patterns, how to validate admin settings, refresh, warehouse sync, and extraction, and when to contact Support.

Lineage View Is Slow or Returns Timeout Errors

Large environments with many databases, schemas, or tables can produce lineage graphs that are slow to load or return timeout errors. Reducing the amount of data that Catalog ingests is the most effective way to improve performance.

Reduce Ingestion Scope with Integration Filters

Several integrations support database-level or project-level allow and block lists that control which assets Catalog extracts. Configuring these filters reduces the size of the lineage graph and improves load times.

Use this table to see which integration surfaces filter-style controls today and what they scope.

IntegrationFilter ParametersWhat It Scopes
Snowflake--db-allowed, --db-blocked, --query-blockedDatabases and query patterns
BigQuery--db-allowed, --db-blockedGCP projects
SQL Server--db-allowed, --db-blockedDatabases
Databricks--catalog-allowed, --catalog-blockedUnity Catalog catalogs
Looker Studio--db-allowed, --db-blocked, --source-queries-onlyGCP projects and source queries
MicroStrategy--project-idsMicroStrategy projects
Tableau--skip-columns, --skip-fieldsColumn and field extraction
Power BIFolder path allow or block patterns configured with your Catalog team; optional Microsoft Fabric capacity boundaries when agreed with your Catalog teamPower BI folders as Catalog stores them in asset paths, often including workspace segments, and capacities that host those workspaces
Confluence--space-ids-allowed, --space-ids-blockedConfluence spaces

Power BI scope is managed on the Catalog integration using folder path patterns rather than the extractor CLI flags listed for some other tools in this table. For design guidance, CI/CD considerations, and how to request changes, read Power BI Setup.

For the full list of parameters, see the castor-extractor documentation for your integration.

Database-Level Filtering in the Lineage View

The lineage view does not support filtering or hiding specific databases from the graph. You can show or hide dashboards and limit lineage to queries from a recent time window, but you can't exclude individual databases after ingestion.

To control which databases appear in lineage, configure allow or block lists at the integration level before the next ingestion run.

Resolve Timeout Errors

Timeout errors mean the request exceeded the allowed server response window. If reducing your ingestion scope doesn't resolve the issue:

  1. Stagger extraction schedules so large integrations don't run at the same time.
  2. Retry the request after a few minutes.
  3. If the error persists, reach out to your Catalog point of contact with the time stamp of the error and a description of what you were doing when it occurred.