Chore(UI): Fix the CustomizeWidget CustomizeLandingPage tests

[aniketkatkar97]

This pull request refactors the landing page widget test utilities in customizeLandingPage.ts to improve reliability and clarity when interacting with deferred (lazy-loaded) widgets. The main changes focus on robustly revealing, asserting, and verifying the presence or absence of widgets that may not be immediately present in the DOM due to deferred rendering.

Improvements to widget detection and interaction:

• Added getLandingPageWidgetSlot to accurately locate widget slots by matching both exact and suffixed layout keys, handling cases where widgets are added dynamically and may have unique IDs.
• Introduced revealLandingPageWidget to ensure that widgets are scrolled into view only if their slot or widget DOM node is present, preventing unnecessary or stalled scroll actions.

Simplification and reliability of widget visibility checks:

• Refactored isLandingPageWidgetVisible to use revealLandingPageWidget and a direct visibility assertion, removing manual scrolling and polling logic for more reliable checks.
• Updated waitForLandingPageWidget to always reveal the widget before asserting its visibility and waiting for any skeleton loaders to disappear, ensuring that loading is complete before proceeding.

Correctness of widget removal assertions:

• Changed removeAndVerifyWidget to assert on the absence of the deferred slot rather than the widget itself, ensuring that the test correctly distinguishes between a widget being removed and merely being out of view (deferred).

Test flow improvements:

• Simplified addAndVerifyWidget to rely on waitForLandingPageWidget for web-first assertions, removing redundant polling and making the flow more straightforward and reliable.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

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

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[github-actions]

✅ Playwright Results — workflow succeeded

Validated commit 1a16bbf9ae998950498a13f93a05d89a24833e06 in Playwright run 31881734404, attempt 1.

✅ 657 passed · ❌ 0 failed · 🟡 2 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) 37m 39s

⏱️ Max setup 3m 9s · max shard execution 19m 38s · max shard-job elapsed before upload 23m 5s · reporting 6s

🌐 220.96 requests/attempt · 2.90 app boots/UI scenario · 11.71% common-shard skew

Optimization targets still in progress:

• Browser traffic was 220.96 requests per attempt (convergence target: fewer than 200).
• Application boot ratio was 2.9 per UI scenario (2030 boots / 699 scenarios; convergence target: at most 1).

Shard	Passed	Failed	Flaky	Skipped	Lifecycle failed	Lifecycle flaky
✅ Shard chromium-01	133	0	0	0	0	0
✅ Shard chromium-02	127	0	0	0	0	0
🟡 Shard chromium-03	120	0	1	0	0	0
✅ Shard chromium-04	127	0	0	0	0	0
🟡 Shard data-asset-rules-01	60	0	1	0	0	0
✅ Shard domain-isolation-01	14	0	0	0	0	0
✅ Shard global-state-01	34	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

🟡 2 flaky test(s) (passed on retry)

• Flow/CustomizeWidgets.spec.ts › KPI Widget (shard chromium-03, 1 retry)
• Features/DataAssetRulesDisabled.spec.ts › Verify the MlModel entity item action after rules disabled (shard data-asset-rules-01, 1 retry)

📦 Download artifacts

How to debug locally

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

[github-actions]

🚦 Removed from the merge queue — failed_checks (2026-08-15T05:29:15Z)

Blocked the queue: playwright-summary

• Postgresql PR Playwright E2E Tests — playwright-summary, playwright-ci-postgresql (chromium-16)

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[gitar-bot]

Code Review ✅ Approved 1 resolved / 1 findings

Refactors landing page widget test utilities and isolation to fix flaky E2E tests for CustomizeWidget and CustomizeLandingPage. The revealLandingPageWidget scroll error handling finding was successfully addressed.

✅ 1 resolved

✅ Edge Case: revealLandingPageWidget scroll no longer swallows errors

📄 openmetadata-ui/src/main/resources/ui/playwright/utils/customizeLandingPage.ts:56-70 📄 openmetadata-ui/src/main/resources/ui/playwright/utils/customizeLandingPage.ts:232
The old scroll helpers all wrapped scroll actions in .catch(() => undefined), tolerating transient failures. revealLandingPageWidget calls slot.scrollIntoViewIfNeeded() / widget.scrollIntoViewIfNeeded() without a catch, and it runs inside isLandingPageWidgetVisible, which is invoked from expect.poll callbacks in verifyDomainCountInDomainWidget/verifyDataProductCountInDataProductWidget. If the element detaches between the count() check and the scroll (or the scroll times out), the thrown error propagates out of the poll callback and fails the whole test instead of retrying — the flakiness the original catches guarded against. Consider .catch(() => undefined) on the scrollIntoViewIfNeeded calls to preserve that resilience.

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}