Fix Playwright custom property and lineage flakes

[harsh-vador]

Describe your changes:

Fixes: N/A - addresses flaky Playwright runs 31664229633, 31553466055, and 31664233665.

I updated table entity navigation to use direct FQN routes where possible, adjusted custom property deletion to assert the captured PATCH response status while verifying the deleted row is gone, and made the Search Export jobs tray download flow refresh the tray state after the export job completes.

RCA

• Run 31664229633: the attached Flow/PlatformLineage.spec.ts was green, but the report's actual PlatformLineage flakes were in Pages/Lineage/PlatformLineage.spec.ts for Verify domain platform view and Verify platform view switching. Both failed in beforeEach while opening the table page: TableClass.visitEntityPage() could fall back to the global-search helper when entityResponseData.fullyQualifiedName was unavailable, and that helper waited for /api/v1/search/query with index=dataAsset. In CI, that search request can be skipped, missed, or fail to match the exact wait predicate, so the test timed out after 30s before reaching the lineage assertions. The retry passed because entity/search timing happened to line up on the second attempt.
• Run 31553466055: the flaky Sql Query and String custom property tests timed out during the cleanup/delete flow inside deleteCreatedProperty(). The helper clicked the delete confirmation save button and then waited only for a metadata-types PATCH response, so if that network wait was missed or delayed the test kept waiting until the full 180s timeout. The trace showed the flow reached the delete confirmation step and the retry completed normally, which points to synchronization in the helper rather than a deterministic product failure.
• Run 31664233665: SearchExport.spec.ts flaked in Export queues a background job and downloads from the jobs tray. The failing attempt spent the test budget waiting for the tray Download button and then surfaced as Target page, context or browser has been closed when the result response wait was registered after timeout shutdown had started. The test was relying on socket/tray UI state to progress from Exporting to Download; if the tray missed or lagged the completion update, the completed job was available through the API but the visible tray state stayed stale. The fix polls the job completion through the authenticated API, then closes/re-opens the tray to trigger its fetch path before locating the Download button inside the tray.

Type of change:

• Bug fix

High-level design:

N/A - small Playwright flake fix.

Tests:

Use cases covered

• Platform lineage setup can open table pages without depending on global search suggestions.
• Custom property delete waits on the metadata type patch and verifies row removal by exact row key.
• Search export waits for async job completion and refreshes the jobs tray before downloading the CSV.

Unit tests

• Not applicable; Playwright helper-only change.

Backend integration tests

• Not applicable (no backend API changes).

Ingestion integration tests

• Not applicable (no ingestion changes).

Playwright (UI) tests

• Updated existing Playwright helpers/spec flow used by the flaky specs.
• Files updated: playwright/support/entity/TableClass.ts, playwright/utils/customProperty.ts, playwright/e2e/Features/SearchExport.spec.ts

Manual testing performed

1. Extracted the attached Playwright HTML reports and confirmed the RCA from structured report JSON.
2. Ran git diff --check successfully.
3. Checked that SearchExport.spec.ts does not introduce waitForTimeout, force: true, or networkidle.
4. UI checkstyle was not run locally because this workspace is missing openmetadata-ui/src/main/resources/ui/node_modules/.bin/organize-imports-cli.

UI screen recording / screenshots:

Not applicable - no product UI changes.

Checklist:

• I have read the CONTRIBUTING document.
• My PR title is Fixes <issue-number>: <short explanation>
• My PR is linked to a GitHub issue via Fixes #<issue-number> above.
• 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.
• For UI changes: I attached a screen recording and/or screenshots above.
• I have added tests (unit / integration / Playwright as applicable) and listed them above.

[github-actions]

❌ PR checklist incomplete

This PR cannot be merged until the following are addressed on its linked issue:

• No GitHub issue is linked. Link an issue in the Development section of the PR (or add Fixes #12345 to the description). For a same-org cross-repo issue, add Fixes open-metadata/<repo>#123 to the description.

The fields live on the linked issue in the Shipping project (open the issue → right sidebar → Projects). After you set them, re-run this check (or push a commit) — issue/project changes do not re-trigger it automatically.

Maintainers can bypass this check by adding the skip-pr-checks label.

[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!

[github-actions]

✅ Playwright Results — workflow succeeded

Validated commit 08bcd06823b19342db64d79d1d940dde32d6f78f in Playwright run 31800214551, attempt 1.

✅ 557 passed · ❌ 0 failed · 🟡 0 flaky · ⏭️ 0 skipped · 🧰 0 lifecycle flaky

Performance

Blocking targets: ✅ met · Optimization targets: 🟡 in progress

Shard-job maxima below are not the full workflow wall time; the linked run includes build, fixture, planning, and reporting.

🕒 Full workflow signal wall (to summary) 53m 18s

⏱️ Max setup 4m 34s · max shard execution 19m 46s · max shard-job elapsed before upload 23m 27s · reporting 5s

🌐 212.94 requests/attempt · 2.82 app boots/UI scenario · 12.31% common-shard skew

Optimization targets still in progress:

• Browser traffic was 212.94 requests per attempt (convergence target: fewer than 200).
• Application boot ratio was 2.82 per UI scenario (1629 boots / 578 scenarios; convergence target: at most 1).

Shard	Passed	Failed	Flaky	Skipped	Lifecycle failed	Lifecycle flaky
✅ Shard chromium-01	138	0	0	0	0	0
✅ Shard chromium-02	122	0	0	0	0	0
✅ Shard chromium-03	139	0	0	0	0	0
✅ Shard data-asset-rules-01	61	0	0	0	0	0
✅ Shard domain-isolation-01	14	0	0	0	0	0
✅ Shard global-state-01	34	0	0	0	0	0
✅ Shard import-export-01	7	0	0	0	0	0
✅ Shard ingestion-01	1	0	0	0	0	0
✅ Shard reindex-01	2	0	0	0	0	0
✅ Shard search-01	10	0	0	0	0	0
✅ Shard search-rbac-01	29	0	0	0	0	0

📦 Download artifacts

How to debug locally

# Download playwright-test-results-<shard> artifact and unzip
npx playwright show-trace path/to/trace.zip    # view trace

[gitar-bot]

Code Review ✅ Approved 1 resolved / 1 findings

Tightened custom property row removal assertion using exact row key matching and improved synchronization for Playwright lineage and search export flakes. No issues found.

✅ 1 resolved

✅ Edge Case: Row removal assertion uses substring text match

📄 openmetadata-ui/src/main/resources/ui/playwright/utils/customProperty.ts:927-929
The new assertion filters rows by hasText: propertyName, which is a substring match. If another custom property name contains propertyName as a substring (or the name appears in another row), the locator still matches a visible row and the assertion fails even after a correct deletion, reintroducing flakiness. Prefer an exact-key locator like page.locator([data-row-key="${propertyName}"]).not.toBeVisible(), consistent with the delete-click locator earlier in this helper.

Options

Display: compact → Showing less information.

Comment with these commands to change the behavior for this request:

Compact

gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Powered by Gitar — free for open source}