Chore(UI): Fix the flakiness in SearchRBAC test - #30768
Conversation
❌ PR checklist incompleteThis PR cannot be merged until the following are addressed on its linked issue:
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 |
Code Review ✅ ApprovedUpdates the SearchRBAC Playwright tests to require explicit entity names in the search utility, improving reliability and eliminating test flakiness. No issues found. OptionsDisplay: compact → Showing less information. Comment with these commands to change the behavior for this request:
Was this helpful? React with 👍 / 👎 | Gitar | Powered by Gitar — free for open source |
✅ Playwright Results — workflow succeededValidated commit ✅ 550 passed · ❌ 0 failed · 🟡 0 flaky · ⏭️ 3 skipped · 🧰 0 lifecycle flaky PerformanceBlocking 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) 58m 57s ⏱️ Max setup 2m 53s · max shard execution 19m 32s · max shard-job elapsed before upload 25m 40s · reporting 3s 🌐 201.31 requests/attempt · 2.83 app boots/UI scenario · 11.77% common-shard skew Optimization targets still in progress:
How to debug locally# Download playwright-test-results-<shard> artifact and unzip
npx playwright show-trace path/to/trace.zip # view trace |
🚦 Removed from the merge queue —
|
🚦 Removed from the merge queue —
|
…ock the merge queue (#30784) * ci(playwright): raise the chromium shard budget to 21 minutes The chromium lane outgrew a 19-minute shard. At the COMMON_MAX_SHARDS ceiling of 24 the heaviest shard is predicted at 19.2m, so assign_lane_within_budget() raises SystemExit and full-mode planning aborts before a single test runs. Every merge_group run today failed this way (PRs #30705, #30768, #30458, #30725, #30754), while pull_request_target runs pass because targeted selection is far smaller. Raise COMMON_SHARD_BUDGET_MS from 19m to 21m. At 24 shards the heaviest is 19.2m, so the loop is guaranteed to converge at or before the ceiling. 21m stays inside the 25m `timeout` wrapper around `npx playwright test` and the 35m playwright-ci-postgresql job clock, leaving ~4m of headroom. Note the common lane now sits 1m above the dedicated lanes rather than 1m below. The strict 20-minute TARGET_MS ceiling is unaffected: it bounds a single atomic unit, not a shard, so a 21m shard built from units each under 20m does not trip it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test(playwright): cover full-mode allocator convergence at the shard ceiling Addresses review on #30784. assign_lane_within_budget() was only exercised in "targeted" mode, so neither the full-mode convergence path nor the SystemExit at COMMON_MAX_SHARDS had coverage -- the exact code path that took the merge queue down. Add both: - test_full_mode_chromium_converges_at_the_shard_ceiling builds a lane that needs the window above 19m and asserts the allocator converges at or before the ceiling. Verified as a real guard: with the budget reverted to 19m it fails with "needs more than 24 shards ... heaviest shard is predicted at 20.4m". - test_full_mode_chromium_reports_a_lane_the_ceiling_cannot_hold pins the SystemExit path, which had no coverage at all. Also reword the budget comment: ~4m of headroom is relative to the 25m playwright timeout wrapper specifically, not to the 35m job clock, which is looser and additionally absorbs setup/teardown. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
🚦 Removed from the merge queue —
|
…ity category (#30800) "Table Column > User without permission" fails deterministically on both 1.13 AUT runs, in two different ways that share one cause: MySQL expect(locator).not.toBeAttached() failed locator('[data-testid="entity-header-display-name"]') .filter({ hasText: 'user_ida06c5f92' }) -- was attached PostgreSQL expect(locator).toBeVisible() failed getByTestId('no-search-results').getByText('No result found.') searchForEntityShouldWorkShowNoResult searches globally and then asserts absence against whatever entity category Explore happens to be showing. A match from an unrelated category leaves a result attached and the "no results" placeholder unrendered -- the two failures above are the same defect seen from either side. Its sibling searchForEntityShouldWork already selects the category before asserting presence (#30768). Apply the same scoping here and pass the category from both call sites, so the negative assertion is made against the category under test rather than the whole index. Note this is not a port of #30768: that change is already on 1.13, and it only touched the positive-case helper. The negative one was missed. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
🚦 Removed from the merge queue —
|
This pull request updates the search RBAC (Role-Based Access Control) Playwright tests to improve reliability and specificity by requiring the entity name to be explicitly provided and used when interacting with the UI. The main changes involve updating the
searchForEntityShouldWorkutility function and its usages to accept and utilize anentityNameparameter, ensuring the correct entity is selected in the UI during tests.Test improvements:
searchForEntityShouldWorkfunction insearchRBAC.tsto require anentityNameparameter, and modified the function to select the correct entity in the UI based on this name. [1] [2]searchForEntityShouldWorkinSearchRBAC.spec.tsto pass the appropriate entity name, ensuring tests are explicit and less prone to flakiness. [1] [2]Greptile Summary
Updates the Search RBAC Playwright flow to select the intended entity category explicitly.
searchForEntityShouldWork.Confidence Score: 5/5
The PR appears safe to merge, with no concrete changed-code defects identified.
The new arguments correspond to the Explore entity-category menu labels, and the helper waits for loading both before and after selecting the requested category.
Important Files Changed
Reviews (1): Last reviewed commit: "Fix the flakiness in SearchRBAC test" | Re-trigger Greptile