Skip to content

fix failing searchIndexApplication - #30577

Merged
shrabantipaul-collate merged 1 commit into
mainfrom
fix-flaky-search-index
Jul 28, 2026
Merged

shrabantipaul-collate merged 1 commit into
mainfrom
fix-flaky-search-index

Conversation

@shrabantipaul-collate

@shrabantipaul-collate shrabantipaul-collate commented Jul 28, 2026 •

Copy link
Copy Markdown
Contributor

Describe your changes:

  • Fixes a flaky/failing assertion in SearchIndexApplication.spec.ts where the run-status check used a hardcoded /success|activeError/g regex instead of the file's own SUCCESSFUL_RUN_STATUS constant (/success|completed|activeError/i).
  • Since the backend reports "completed" for successful runs, the stale regex rejected a valid passing status.
  • Both call sites now reuse the shared constant.

Fixes #

I worked on ... because ...

Type of change:

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

High-level design:

N/A — small change.

Tests:

Use cases covered

Unit tests

Backend integration tests

Ingestion integration tests

Playwright (UI) tests

Manual testing performed

UI screen recording / screenshots:

Not applicable.

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.

Greptile Summary

This PR fixes SearchIndexApplication Playwright status assertions by:

  • Reusing the existing SUCCESSFUL_RUN_STATUS constant at both duplicated assertion sites.
  • Accepting the backend’s valid completed status.
  • Avoiding the stateful global regex previously used by the assertions.

Confidence Score: 5/5

The PR appears safe to merge because the assertions now consistently recognize the backend’s valid completed status.

The changed test assertions reuse a non-global shared matcher that covers the established successful terminal statuses without altering production behavior.

Important Files Changed

Filename Overview
openmetadata-ui/src/main/resources/ui/playwright/e2e/Pages/SearchIndexApplication.spec.ts Replaces two stale inline status regexes with the file’s shared successful-run status matcher; no actionable issues identified.

Reviews (1): Last reviewed commit: "fix flaky searchIndexApplication" | Re-trigger Greptile

@shrabantipaul-collate
shrabantipaul-collate requested a review from a team as a code owner July 28, 2026 10:51
@github-actions

Copy link
Copy Markdown
Contributor

❌ 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 github-actions Bot added the UI UI specific issues label Jul 28, 2026
@github-actions

Copy link
Copy Markdown
Contributor

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!

@gitar-bot

gitar-bot Bot commented Jul 28, 2026

Copy link
Copy Markdown
Code Review ✅ Approved

Updates SearchIndexApplication.spec.ts to reuse the SUCCESSFUL_RUN_STATUS constant for run-status assertions, fixing flaky test failures caused by stale regex matching. No issues found.

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 👍 / 👎 | Gitar | Powered by Gitar — free for open source

@github-actions

github-actions Bot commented Jul 28, 2026 •

Copy link
Copy Markdown
Contributor

✅ Playwright Results — workflow succeeded

Validated commit 56cfd624d447a424ca44096367fc7d89cf29e463 in Playwright run 30352558107, attempt 1.

✅ 47 passed · ❌ 0 failed · 🟡 0 flaky · ⏭️ 3 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) 39m 34s

⏱️ Max setup 1m 32s · max shard execution 5m 46s · max shard-job elapsed before upload 9m 8s · reporting 3s

🌐 134.04 requests/attempt · 1.35 app boots/UI scenario · 0.00% common-shard skew

Optimization targets still in progress:

  • Application boot ratio was 1.35 per UI scenario (66 boots / 49 scenarios; convergence target: at most 1).
Shard Passed Failed Flaky Skipped Lifecycle failed Lifecycle flaky
✅ Shard chromium-01 47 0 0 3 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

@shrabantipaul-collate shrabantipaul-collate added the safe to test Add this label to run secure Github workflows on PRs label Jul 28, 2026
@shrabantipaul-collate
shrabantipaul-collate added this pull request to the merge queue Jul 28, 2026
Merged via the queue into main with commit 43df581 Jul 28, 2026
122 of 136 checks passed
@shrabantipaul-collate
shrabantipaul-collate deleted the fix-flaky-search-index branch July 28, 2026 14:26
shrabantipaul-collate added a commit that referenced this pull request Jul 29, 2026
Co-authored-by: Shrabanti Paul <shrabantipaul@Shrabantis-MacBook-Pro.local>
shrabantipaul-collate added a commit that referenced this pull request Jul 31, 2026
Co-authored-by: Shrabanti Paul <shrabantipaul@Shrabantis-MacBook-Pro.local>
(cherry picked from commit 43df581)
ShaileshParmar11 added a commit that referenced this pull request Aug 1, 2026
…cation spec

SearchIndexApplication.spec.ts fails deterministically on both 1.13 AUT
runs (MySQL and PostgreSQL), 3/3 attempts:

    ReferenceError: SUCCESSFUL_RUN_STATUS is not defined
      at verifyLastExecutionRun (SearchIndexApplication.spec.ts:158:31)

214e5c5 cherry-picked #30577 onto 1.13, replacing the inline regex
/success|activeError/g with the identifier SUCCESSFUL_RUN_STATUS at two
call sites. That identifier is declared by #27971 (ed5e68c), which
`git branch -r --contains` places on main and 2.0 only -- not 1.13. The
pick applied cleanly because the surrounding context matched, and
introduced a guaranteed ReferenceError.

Declare the constant with the same value it carries on main and 2.0.
Verified there is no second undeclared identifier: SEARCH_INDEX_APP_NAME
exists on main but is never referenced by the 1.13 copy.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ShaileshParmar11 added a commit that referenced this pull request Aug 1, 2026
… fixtures, tour badge (#30787)

* test(playwright): create beforeAll fixtures concurrently on 1.13

Two specs fail on the 1.13/MySQL AUT run with:

    "beforeAll" hook timeout of 60000ms exceeded

Both hooks are pure API setup with no UI interaction, and both pass on
every other branch/database -- this is latency accumulation under load,
not a defect in the code under test.

Pagination.spec.ts creates 20 users one at a time in a for loop, each
awaited. CustomProperties.spec.ts does the same with 5 users on the
entity_table path, which is exactly the case that failed, and with two
topics on the entity_dashboard path. Twenty sequential round-trips
exhaust a 60s budget on latency alone once the backend is loaded.

Construct the instances first, then create them concurrently with
Promise.all. This removes the accumulation rather than tolerating it --
deliberately not a timeout increase, which would only move the cliff.
Each instance still generates its own uuid-suffixed name, so concurrent
creation cannot collide.

CustomProperties.spec.ts is describe.serial, so its hook failure also
skipped 29 downstream tests; those execute again once the hook fits.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* fix(test): declare SUCCESSFUL_RUN_STATUS in the 1.13 SearchIndexApplication spec

SearchIndexApplication.spec.ts fails deterministically on both 1.13 AUT
runs (MySQL and PostgreSQL), 3/3 attempts:

    ReferenceError: SUCCESSFUL_RUN_STATUS is not defined
      at verifyLastExecutionRun (SearchIndexApplication.spec.ts:158:31)

214e5c5 cherry-picked #30577 onto 1.13, replacing the inline regex
/success|activeError/g with the identifier SUCCESSFUL_RUN_STATUS at two
call sites. That identifier is declared by #27971 (ed5e68c), which
`git branch -r --contains` places on main and 2.0 only -- not 1.13. The
pick applied cleanly because the surrounding context matched, and
introduced a guaranteed ReferenceError.

Declare the constant with the same value it carries on main and 2.0.
Verified there is no second undeclared identifier: SEARCH_INDEX_APP_NAME
exists on main but is never referenced by the 1.13 copy.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* test(playwright): assert the tour badge with a single web-first assertion

Tour.spec.ts fails on 1.13/MySQL (flaky on 1.13/PostgreSQL) with

    TimeoutError: locator.waitFor: Timeout 10000ms exceeded
      waiting for locator('[data-tour-elem="badge"]') to be visible
      at expectTourBadge (Tour.spec.ts:48)

The failing call is mid-tour (validateTourSteps line 82), not the first
one -- waitForTourBadgeWithRetry has already established the badge by
then. The badge re-renders on each step transition, and expectTourBadge
gave that transition two independent budgets to lose against: a
visibility waitFor, then a separate text poll, each capped at 10s --
the tightest timeout in any failing spec.

Replace both with one toHaveText assertion. It auto-waits for the badge
to attach *and* carry the expected step under a single budget, and
reports the actual step on failure instead of "not visible".

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* test(playwright): keep partially-created fixtures reachable for teardown

Addresses review on #30787.

With Promise.all, a rejection from any one create skips the
users.push(...newUsers) that follows it, so users created successfully
by the siblings never reach the afterAll loop that deletes them and
leak into the environment.

Use Promise.allSettled, register every fulfilled instance for teardown,
then rethrow the first rejection. The hook still fails on a genuine
create error -- nothing is swallowed -- but cleanup no longer depends on
all five succeeding.

Pagination.spec.ts needs no equivalent change: it has no afterAll for
its users, before or after this branch.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* test(playwright): register fixtures by persisted id, not promise outcome

Addresses the second review round on #30787.

UserClass.create() persists the user through /users/signup and sets
responseData before it assigns roles, so a rejection from the role
patch still leaves a real user behind. Registering only the fulfilled
results therefore still leaked exactly the case allSettled was added
to cover.

Register every instance that came back with an id, regardless of how
its promise settled, and rethrow the first rejection as before.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

This branch was previously deployed

1 inactive deployment
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

safe to test Add this label to run secure Github workflows on PRs UI UI specific issues

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants