A dbt model with no parents can keep old OpenMetadata lineage

An OpenMetadata issue reports a specific zero-dependency gap: overrideLineage: true replaces one nonempty parent set with another, but leaves old dbt edges when the new manifest has depends_on.nodes: []. Ingestion still succeeds. A lineage graph can therefore tell an analyst that a removed upstream table affects a model, even though the compiled model no longer references it. This is a reported bug in tested versions, not proof about every deployment.

Compare the manifest with the lineage API

Pick a model whose dependency set was intentionally removed. Save the previous and current manifest.json, including the node's depends_on.nodes. Query the model's upstream lineage via the API after ingestion, then compare edge IDs and source types. A green ingestion job only shows that extraction and write steps completed; it does not verify that a zero-parent state deleted prior edges. The issue reproduces the difference between an existing service and a fresh one.

Scope remediation carefully

The reporter says explicit deletion of the model's DbtLineage edges clears the stale state. That is a targeted, destructive metadata change, so take a lineage snapshot, confirm the model ID and source type, and use an approved maintenance window before testing it. Do not clear manual or other-source lineage by broad deletion. Check downstream impact views and metadata consumers after the correction.

Add a regression gate

In CI or a scheduled metadata check, compare manifest parent sets with source-scoped OpenMetadata edges for a sample of changed models. Include the empty-set transition; tests that only swap parent A for C will miss this defect. Escalate the minimal reproducer and version numbers to the project maintainers.

Adovo’s view

Lineage is a dependency claim. Empty is a real value, not an absence of work. A trustworthy catalog must prove that deleting the last dependency deletes the last edge.