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

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 and we'll increase the setting.

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.

We suggest renaming the temporary table to 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.

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

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.

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
Confluence--space-ids-allowed, --space-ids-blockedConfluence spaces

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.