chore(ui): Add Test Case list filters while creating a bundle suite

[shah-harshit]

Description

Adds filters to the Add Test Case modal (when creating a test suite or adding test cases): Status (single), Test type (single), Table (multi), Column (multi). Uses SearchDropdown for all four; Table/Column are client-side filtered, Status/Test type trigger API refetch.

Screen.Recording.2026-03-06.at.7.06.03.PM.mov

Changes

• AddTestCaseList: filter state (status, testType, table, column), filteredItems from filterTestCasesByTableAndColumn, API refetch on Status/Test type change
• AddTestCaseListFilters: new component + constants (filter keys, config) and interface
• AddTestCaseList.utils: getTableFilterOptions, getColumnFilterOptions, getSelectedOptionsFromKeys, filterTestCasesByTableAndColumn
• profiler.constant: TEST_CASE_TYPE_FILTER_OPTIONS, TEST_CASE_STATUS_FILTER_OPTIONS (used by filters)
• Unit tests: AddTestCaseList.component.test.tsx (filter visibility, Test type/Status refetch, table/column client-side filter), AddTestCaseList.utils.test.ts
• E2E: TestSuite.spec.ts — separate steps: open form, filters (verify/apply/clear), select test case and create; correct filter test ids (search-dropdown-Status, etc.)

Issue

Fixes https://github.com/open-metadata/openmetadata-collate/issues/3045

Made with Cursor

[github-actions]

Hi there 👋 Thanks for your contribution!

The OpenMetadata team will review the PR shortly! Once it has been labeled as safe to test, the CI workflows
will start executing and we'll be able to make sure everything is working as expected.

Let us know if you need any help!

[shah-harshit]

@gitar-bot review the PR again. I have addressed your comments.

[gitar-bot]

@gitar-bot review the PR again. I have addressed your comments.

Thanks for the update! I can confirm the onScroll stale closure issue (minor finding) has been addressed — fetchTestCases and pageNumber are now in the dependency array.

The important finding regarding client-side Table/Column filtering is still present — tableOptions/columnOptions are derived only from the currently loaded items, so tables/columns on later pages won't appear as filter options, and the pagination count remains server-side while the visible list is a client-side subset.

If this is intentional (e.g., for simplicity or because the use case doesn't require filtering across all pages), please clarify and I'll close the finding. Otherwise, making Table/Column filters server-side (like Status/Test Type) would fully resolve it.

[shah-harshit]

@gitar-bot Table/Column filters on the client-side are intentional.

[gitar-bot]

@gitar-bot Table/Column filters on the client-side are intentional.

Understood — client-side filtering for Table/Column is intentional. Thanks for clarifying!

[github-actions]

Jest test Coverage

UI tests summary

Lines	Statements	Branches	Functions
	66.04% (57363/86856)	45.65% (30225/66197)	48.48% (9096/18760)

[gitar-bot]

🔍 CI failure analysis for 62f0e8e: The `playwright-ci-postgresql (2, 6)` job fails due to a race condition in the new E2E test in `TestSuite.spec.ts` — `waitForResponse` is registered after the action that triggers the API call.

Issue

The playwright-ci-postgresql (2, 6) job fails with 1 test failing and 2 flaky tests.

The definitive failure is:

[ingestion] › playwright/e2e/Pages/TestSuite.spec.ts:53:5 › Logical TestSuite @ingestion › Open create test suite form
Test timeout of 180000ms exceeded.
Error: page.waitForResponse: Target page, context or browser has been closed
waiting for response "/api/v1/dataQuality/testCases/search/list*"

This failure persisted through retry #1 with the same error.

Root Cause

The new test code introduced in this PR has a race condition in the 'Open create test suite form' step (TestSuite.spec.ts:75):

await page.click('[data-testid="add-test-suite-btn"]');  // triggers API call
await page.fill('[data-testid="test-suite-name"]', ...);
await page.locator(descriptionBox).fill(...);

// ❌ waitForResponse registered AFTER the click that triggers the request
const initialListResponse = page.waitForResponse(
  `/api/v1/dataQuality/testCases/search/list*`
);
await initialListResponse;

page.waitForResponse() must be called before the action that triggers the network request. If the response arrives before the listener is registered, Playwright will wait indefinitely until the browser context times out and closes. The fix is to set up waitForResponse before page.click('[data-testid="add-test-suite-btn"]').

Details

• Failed test: playwright/e2e/Pages/TestSuite.spec.ts:53 — directly modified by this PR
• Flaky tests (unrelated to this PR):
  • AutoPilot.spec.ts:187 — MlFlow agent deletion toast notification received wrong service name (timing/ordering issue)
  • ServiceForm.spec.ts:77 — ENOENT on cert file cleanup in afterAll (environment cleanup race)
• The two flaky tests passed on retry and are pre-existing infrastructure issues unrelated to this PR's changes.

Code Review ✅ Approved 3 resolved / 3 findings

UI enhancement adding test case list filters to bundle suite creation, with stale callback reference and missing useMemo dependency resolved. No remaining issues found.

✅ 3 resolved

✅ Bug: onScroll callback has stale fetchTestCases reference

📄 openmetadata-ui/src/main/resources/ui/src/components/DataQuality/AddTestCaseList/AddTestCaseList.component.tsx:215
onScroll (line 215) calls fetchTestCases and reads pageNumber, but neither is in its dependency array (line 228). This was pre-existing, but is now more impactful: when filterStatus or filterTestType changes, fetchTestCases gets a new reference (it depends on them via its own useCallback deps), but onScroll retains the old closure. If a user changes a filter and then scrolls to load more, the scroll-triggered fetch will use the previous filter values.

Add fetchTestCases and pageNumber to the onScroll dependency array.

✅ Bug: renderList useMemo missing onScroll dependency

📄 openmetadata-ui/src/main/resources/ui/src/components/DataQuality/AddTestCaseList/AddTestCaseList.component.tsx:368
The renderList memoized value uses onScroll (passed to VirtualList at line 302) but onScroll is not listed in the dependency array at lines 368-375. This means when onScroll changes (e.g. because fetchTestCases or pageNumber changed), renderList may hold a stale closure.

In practice this is partially masked because items (which IS in the deps) typically changes alongside pageNumber, triggering a re-render anyway. However, there's a window where the scroll handler could be stale—particularly if a filter change causes fetchTestCases (and thus onScroll) to update before the API response arrives and updates items.

React's own lint rule (react-hooks/exhaustive-deps) would flag this.

✅ Bug: Client-side table/column filters only apply to loaded page(s)

📄 openmetadata-ui/src/main/resources/ui/src/components/DataQuality/AddTestCaseList/AddTestCaseList.component.tsx:104 📄 openmetadata-ui/src/main/resources/ui/src/components/DataQuality/AddTestCaseList/AddTestCaseList.component.tsx:147 📄 openmetadata-ui/src/main/resources/ui/src/components/DataQuality/AddTestCaseList/AddTestCaseList.component.tsx:271
The Table and Column filters are applied client-side on items (the set of test cases loaded so far via infinite scroll), while Status and Test Type are sent as server-side API parameters. This creates several problems:

1. Incomplete filter options: tableOptions and columnOptions are derived from items (lines 104-106), which only contains the first page (25 items) or whatever has been scrolled into view. Tables/columns that exist on later pages won't appear as filter options.

2. Misleading results: When a table/column filter is active, the total item count in the pagination header still reflects the server's unfiltered total (line 181: setTotalCount(testCaseResponse.paging.total ?? 0)), while the visible list is a client-side subset. Users may see "3 of 50" items but no way to load the other 47 matching items.

3. Infinite scroll breaks: The onScroll handler (line 217-219) compares items.length < totalCount to decide whether to fetch more, but after client-side filtering listSource could have fewer items than items, causing the virtual list to stop scrolling before all server-side results are loaded.

Consider making table and column filters server-side (API parameters) like status and test type, or fetch all results before enabling client-side filtering.

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}

[sonarqubecloud]

Quality Gate passed for 'open-metadata-ui'

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