MINOR - test case summary list optimization

[TeddyCr]

Describe your changes:

• Remove expensive batchResolveEntityLinks from the batch /search/list path — it loaded all TestCase entities from DB just to resolve entityLink for column-level breakdowns the frontend list view never uses
• Replace with computeSimpleSummary that computes status counts (total/success/failed/aborted/queued) directly from ResultSummary objects in memory
• Stop populating testCaseResultSummary in the batch path and add it to clearFields to prevent data leakage into responses

Performance Benchmark

Test setup: 10 test suites x 20 test cases x 50 results = 10,000 total test case results

Before vs After

Benchmark	Before (Avg)	After (Avg)	Improvement
WITHOUT summary (limit=10)	—	96ms	baseline
WITH summary (limit=10)	2,105ms	174ms	12x faster
WITH summary (limit=50)	—	197ms	—
WITH summary+tests (limit=10)	2,105ms	168ms	12.5x faster

Detailed After-Fix Numbers

Benchmark	Min	Avg	P50	P95	Max
WITHOUT summary	91ms	96ms	94ms	106ms	106ms
WITH summary (limit=10)	148ms	174ms	170ms	222ms	222ms
WITH summary (limit=50)	174ms	197ms	202ms	227ms	227ms
WITH summary+tests (limit=10)	155ms	168ms	171ms	185ms	185ms

Server-Side Metrics

Metric	Before	After
DB operations per request	5,224	Below slow-request threshold
DB time %	84% (1,668ms)	—
Slow request warnings	Every request	Zero

Root Cause

fetchAndSetTestCaseResultSummary called batchResolveEntityLinks which invoked Entity.getEntityByNames(TEST_CASE, ...) to load ~200 full TestCase JSON blobs from the database — just to extract the entityLink field for column-level summary breakdowns. The frontend list view (TestSuites.component.tsx) only uses summary.total and summary.success, never testCaseResultSummary or column breakdowns.

Changes

TestSuiteRepository.java

• fetchAndSetTestCaseResultSummary — Removed batchResolveEntityLinks call and testCaseResultSummary population. Now computes summary directly from status values via new computeSimpleSummary method.
• clearFields — Added testCaseResultSummary clearing to prevent leaking per-test-case detail into list responses.
• Removed batchResolveEntityLinks — Dead code after the above change.

TestSuiteResourceTest.java

• Updated test_testSuiteReindexConsistency to assert on summary (total/success counts) instead of testCaseResultSummary, matching the new batch path behavior.

Type of change:

• Bug fix
• Improvement
• New feature
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation

Checklist:

• I have read the CONTRIBUTING document.
• My PR title is Fixes <issue-number>: <short explanation>
• I have commented on my code, particularly in hard-to-understand areas.
• For JSON Schema changes: I updated the migration scripts or explained why it is not needed.

Improvement

• I have added tests around the new logic.
• For connector/ingestion changes: I updated the documentation.

[gitar-bot]

🔍 CI failure analysis for 9c70023: CI failures persist for commit 9c70023: maven-sonarcloud-ci retried but failed again with the SAME 6 DataProductResourceTest failures (not flaky, consistently failing), plus persistent Elasticsearch infrastructure issues in integration tests.

Issue

Multiple CI jobs failed for commit 9c700237ad: persistent failures in both unit tests and integration tests.

Root Cause

1. Persistent DataProduct test bugs: Two retry attempts both failed with identical 6 test failures (not flaky)

2. Systemic Elasticsearch infrastructure issues: Three retry attempts all failed with different tests

3. Other issues: External workflow failure, Playwright flakiness

Details

maven-sonarcloud-ci - Second attempt, same failures (NOT flaky)

1st attempt (job 64225079804): 6 DataProductResourceTest failures
2nd attempt (job 64240233218): Same exact 6 DataProductResourceTest failures

Unit tests: 7966 tests run, 701 skipped, 6 failed

All 6 failures in DataProductResourceTest.java:

1. Line 850: expected: <success> but was: <failure> (consistent)
2. Line 1108: expected: <1> but was: <0> (consistent)
3. Line 1066: expected: <1> but was: <0> (consistent)
4. Line 1012: expected: <1> but was: <0> (consistent)
5. Line 1732: Output port should be in target domain after migration ==> expected: <26593cff-f9f5-4b1f-a33e-c8229f5bf8c7> but was: <a1ca6845-54fb-4d3d-acb6-63a5c9d2b8fe> (consistent assertion failure, UUIDs differ due to test data)
6. Line 904: status code: 400, reason phrase: Error reading response: status code: 400, reason phrase: Unknown error (consistent)

Analysis: The retry failed with exactly the same 6 tests in both attempts. This is NOT a flaky test scenario - these are persistent test bugs or pre-existing issues in DataProductResourceTest.java. The failures consistently involve:

• Status validation returning "failure" instead of "success"
• Entity counts consistently returning 0 instead of 1
• Domain migration consistently failing (wrong target domain)
• HTTP 400 errors consistently occurring

Test Report (job 64253341551)

Cascading failure from maven-sonarcloud-ci.

integration-tests-mysql-elasticsearch - Three retries, three different failures

1st: Chart/Glossary timeouts
2nd: Domain timeout
3rd: Glossary update timeout + all shards failed error

Systemic Elasticsearch infrastructure issues.

Other persistent failures

• integration-tests-postgres-opensearch: Search index timeout
• Test Report (integration): Cascading failure
• maven-collate-ci: External workflow failure
• playwright-ci-postgresql: 1 failed, 7 flaky E2E tests

PR relevance: This PR (commit 9c700237ad) refactored TestSuiteRepository.java, replacing Java Stream collectors with imperative loops for computeSimpleSummary. The changes:

• Do not affect DataProductResource, domain migration, search indexing, or any failing test areas
• Are isolated to test suite summary computation in TestSuiteRepository

All failures are unrelated to the PR changes. The DataProduct tests are not flaky - they fail consistently, indicating pre-existing bugs in DataProductResourceTest.java unrelated to this PR.

Code Review ✅ Approved

Clean, well-scoped performance optimization that replaces expensive batch entity resolution with in-memory status aggregation. No bugs, security issues, or correctness concerns found.

Tip

Comment Gitar fix CI or enable auto-apply: gitar auto-apply:on

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[harshach]

Map<Status, Integer> counts = new EnumMap<>(Status.class);

for (ResultSummary r : results) {
Status status = r.getStatus();
counts.merge(status, 1, Integer::sum);
}

[sonarqubecloud]

Quality Gate passed for 'open-metadata-ingestion'

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud