DQ Status Not Propagated to Lineage-Linked Assets in Large Catalogs

[Prajwal214]

Affected module

UI

Describe the bug

DQ failure status is not propagated to downstream assets through lineage, causing the DQ failure icon to be missing on lineage-linked assets.

To Reproduce

1. Configure lineage between upstream and downstream tables.
2. Ensure the upstream table has a failing DQ test in its latest run.
3. Have more than 100 test cases across the instance, with sufficient test result history for the issue to occur.
4. Check the downstream asset's DQ status or call the following API:

GET /api/v1/lineage/getDataQualityLineage?fqn=<downstream asset>&upstreamDepth=1

5. Observe whether the upstream failure is reflected in the lineage DQ response and downstream asset icon.

Expected behavior

The lineage DQ check should correctly identify failing test cases for the relevant upstream assets, regardless of the total number of test cases or results across the instance.

OS

No response

Python version

No response

OpenMetadata version

1.13.6

OpenMetadata Ingestion package version

No response

Additional context

No response

Pre-submission checklist

• I searched for duplicate issues.
• I removed credentials, hostnames, emails, and other sensitive data from logs and config.

[manerow]

Root cause confirmed and reproduced locally. This is a backend bug; the "Affected module: UI" above should read backend.

Why it happens. For each lineage node, getDataQualityLineage asks "does this asset have a failing test right now?" through TestCaseResultRepository.hasTestCaseFailure. That query:

1. groups every test result in the instance by test case;
2. keeps the 100 test cases with the most results;
3. only then filters to the asset.

On a large catalog the upstream table's failing test is usually not among those 100, so the downstream asset shows no icon. This has been the case since 1.10.0 (#23120); up to 1.9 the asset filter ran first. "It used to work" means the number of test cases grew past the cap, not that 1.13.6 changed anything.

Local reproduction. Lineage U → D, with 3 failing tests on U.

• With 86 test cases in the instance, the endpoint returns U.
• After adding 20 test cases with 2 results each on an unrelated table, U's tests ranked 103 to 105 and nodes came back empty.

How to confirm on an affected instance (admin token):

• GET /api/v1/dataQuality/testCases/testCaseResults/search/list?entityFQN=<upstream>&latest=true&limit=0 returns [] when affected.
• The same call with limit=10 lists the failures.

Fix plan. Check all lineage nodes in one query against the test case index, matching the owning asset exactly. That index holds each test case's current status, which is the same source the table's own DQ icon and Data Quality tab use. Backports to 2.0 and 1.13.

Related:

• Late or deleted test results leave a test case's status and incident out of date #34277: the stored status can go stale when results arrive late or are deleted. It ships together with this fix.
• Latest-result listings group the whole index before filtering, capping results and slowing every request #34278: the shared query behind the cap. Main only.