Fixes #26970: fix bot name search on the Bots page

[siddhiguptas]

Describe your changes:

Fixes #26970
This change replaces client-side bot filtering on the Bots page with API-driven search so bot name and bot email searches both work reliably.
I worked on this because bot search should be consistent and accurate for both bot names and email-like identifiers, and API search is the expected behavior for this page.
Changes made:

• removed local bot filtering logic from BotListV1 and switched search flow to API
• added getBotByName in botsAPI.ts and used it to resolve matched bot users into bot entities
• updated Bots page search to:
  • search bot users via searchQuery (SearchIndex.USER + isBot:true)
  • fetch matching bots from backend by bot name
  • enrich bot-user fields for consistent display/search behavior
• removed now-unnecessary client-side helper logic/tests from BotsUtils.tsx and BotsUtils.test.tsx
• kept/updated Playwright coverage for searching by bot name and email in:
  • playwright/e2e/Pages/Bots.spec.ts
  • playwright/utils/bot.ts
    Testing:
• Ran:
  • git diff --check
  • yarn lint:base src/components/Settings/Bot/BotListV1/BotListV1.component.tsx src/rest/botsAPI.ts src/utils/BotsUtils.tsx src/utils/BotsUtils.test.tsx
  • yarn lint:base playwright/e2e/Pages/Bots.spec.ts playwright/utils/bot.ts
  • yarn pretty:base --check src/components/Settings/Bot/BotListV1/BotListV1.component.tsx src/rest/botsAPI.ts src/utils/BotsUtils.tsx src/utils/BotsUtils.test.tsx playwright/e2e/Pages/Bots.spec.ts playwright/utils/bot.ts
  • yarn test src/components/Settings/Bot/BotListV1/BotListV1.component.test.tsx --watch=false
  • yarn test src/utils/BotsUtils.test.tsx --watch=false
• Result:
  • all passed
    Note:
• make ui-checkstyle-src-changed could not be completed in this environment due missing antlr4 binary in PATH during UI postinstall/build-check.

Type of change:

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

Checklist:

• I have read the CONTRIBUTING document.
• My PR title is Fixes <issue-number>: <short explanation>
• 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.
  Not applicable. This PR only updates UI/API search behavior and related tests; there is no schema or migration impact.
• I have added a test that covers the exact scenario we are fixing. For complex issues, comment the issue number in the test for future reference.

---

Screen Recording - https://drive.google.com/file/d/1HisqYIXrGDWtM9-nFI-urc2FXB2S58vk/view?usp=drive_link

---

Summary by Gitar

• Test utilities enhancement:
  • Added searchFromSearchInput and updateSearchInputAndWait in common.ts to handle standardized search input with API response waiting.
• Test coverage:
  • Added verifyBotSearch utility to validate bot searching by name and email in bot.ts.
  • Integrated verifyBotSearch into the main Bots.spec.ts test suite.

_{This will update automatically on new commits.}

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

[Copilot]

Pull request overview

Fixes bot search behavior on the UI Bots page by making client-side filtering consistently case-insensitive (and normalized) across both the user’s search input and the bot fields being searched, addressing issue #26970.

Changes:

• Added a shared filterBotsBySearchTerm helper to centralize bot search matching logic.
• Updated BotListV1 to use the shared helper instead of inline filtering logic.
• Added regression unit tests to cover display name/name matching and email-style identifier matching.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
openmetadata-ui/src/main/resources/ui/src/utils/BotsUtils.tsx	Introduces shared bot filtering helper with consistent normalization across searched fields.
openmetadata-ui/src/main/resources/ui/src/utils/BotsUtils.test.tsx	Adds unit tests validating case-insensitive and email-style bot search matching.
openmetadata-ui/src/main/resources/ui/src/components/Settings/Bot/BotListV1/BotListV1.component.tsx	Switches Bots page filtering to use the shared helper and removes now-unneeded inline normalization.

[harsh-vador]

@siddhiguptas we need to implement api search here and not client side search, please make changes accordingly

[github-actions]

Jest test Coverage

UI tests summary

Lines	Statements	Branches	Functions
	61.89% (61781/99816)	42.05% (33023/78523)	45.04% (9763/21673)

[github-actions]

🔴 Playwright Results — 1 failure(s), 19 flaky

✅ 3953 passed · ❌ 1 failed · 🟡 19 flaky · ⏭️ 86 skipped

Shard	Passed	Failed	Flaky	Skipped
🔴 Shard 1	295	1	3	4
🟡 Shard 2	753	0	6	8
🟡 Shard 3	730	0	2	7
🟡 Shard 4	755	0	4	18
✅ Shard 5	687	0	0	41
🟡 Shard 6	733	0	4	8

Genuine Failures (failed on all attempts)

❌ Pages/Bots.spec.ts › Bots Page should work properly (shard 1)

�[31mTest timeout of 180000ms exceeded.�[39m

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

• Flow/Tour.spec.ts › Tour should work from welcome screen (shard 1, 1 retry)
• Flow/Tour.spec.ts › Tour should work from URL directly (shard 1, 1 retry)
• Pages/AuditLogs.spec.ts › should apply both User and EntityType filters simultaneously (shard 1, 1 retry)
• Features/ActivityAPI.spec.ts › Activity event is created when description is updated (shard 2, 1 retry)
• Features/ActivityAPI.spec.ts › Activity event is created when owner is added (shard 2, 1 retry)
• Features/AdvancedSearch.spec.ts › Verify Group functionality for field Name with AND operator (shard 2, 1 retry)
• Features/DomainFilterQueryFilter.spec.ts › Domain filter should persist across page navigation (shard 2, 1 retry)
• Features/DomainFilterQueryFilter.spec.ts › Domain filter should use exact match and prefix with dot to prevent false positives (shard 2, 1 retry)
• Features/Glossary/GlossaryWorkflow.spec.ts › should start term as Draft when glossary has reviewers (shard 2, 2 retries)
• Features/RTL.spec.ts › Verify Following widget functionality (shard 3, 1 retry)
• Features/UserProfileOnlineStatus.spec.ts › Should show online status badge on user profile for active users (shard 3, 1 retry)
• Pages/CustomProperties.spec.ts › Set & Update all CP types on apiCollection (shard 4, 1 retry)
• Pages/DataContracts.spec.ts › Create Data Contract and validate for Container (shard 4, 1 retry)
• Pages/DataContractsSemanticRules.spec.ts › Validate Description Rule Is_Set (shard 4, 1 retry)
• Pages/DataContractsSemanticRules.spec.ts › Validate Description Rule Is_Not_Set (shard 4, 1 retry)
• Pages/LearningResources.spec.ts › should create resource via UI and verify learning icon appears on target page (shard 6, 1 retry)
• Pages/Lineage/LineageFilters.spec.ts › Verify lineage schema filter selection (shard 6, 1 retry)
• Pages/Lineage/LineageRightPanel.spec.ts › Verify custom properties tab IS visible for supported type: searchIndex (shard 6, 1 retry)
• Pages/UserDetails.spec.ts › Create team with domain and verify visibility of inherited domain in user profile after team removal (shard 6, 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

[siddhiguptas]

@harsh-vador fixed

[harsh-vador]

@siddhiguptas there is a failing playwright check, can you please fix it?

[siddhiguptas]

@harsh-vador I’ve narrowed the changes to bot-only scope. I kept updates in playwright/utils/bot.ts for the failing bot flow and left out-of-scope files untouched: playwright/utils/user.ts, playwright/e2e/Flow/Tour.spec.ts, and playwright/e2e/Features/CustomizeDetailPage.spec.ts. Those files are unrelated to the bot API search implementation, so I excluded them to keep this PR focused.

[harsh-vador]

@siddhiguptas try to run the Bots.spec.ts on your local and test your bot related changes, because the spec was failing

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (1)

openmetadata-ui/src/main/resources/ui/playwright/utils/bot.ts:105

• createBot now asserts revoke-button, center-panel, and token-expiry without navigating to the bot details page. Those elements are rendered on the bot details view (as implied by the existing getCreatedBot helper and by subsequent steps like updateBotDetails), so this helper will be brittle/fail if the create flow returns to the listing page. Consider restoring the explicit navigation (click the created bot link or route to /bots/{fqn}) before asserting details-page controls.

  // Verify bot is getting added in the bots listing page
  await expect(
    page.getByTestId(`bot-link-${BOT_DETAILS.botName}`)
  ).toBeVisible();

  await expect(
    page.getByRole('cell', { name: BOT_DETAILS.description })
  ).toBeVisible();

  await expect
    .poll(async () => page.getByTestId('revoke-button').count(), {
      timeout: 30000,
    })
    .toBeGreaterThan(0);

  await expect(page.getByTestId('revoke-button')).toContainText('Revoke token');

  await expect(page.getByTestId('center-panel')).toContainText(
    `${BOT_DETAILS.JWTToken} Token`
  );

  await expect(page.getByTestId('token-expiry')).toBeVisible();

[siddhiguptas]

hey @harsh-vador I tried to fix things but that one Playwright tests is still falling. I tired to look into the logs and the test is failing for the files we haven't touched.

[harsh-vador]

@siddhiguptas can you please update the PR description with screen recording?

[siddhiguptas]

@siddhiguptas can you please update the PR description with screen recording?

@harsh-vador updated

[siddhiguptas]

Hi @harsh-vador, I investigated the latest CI run and found two tracks: for the bot flow, the timeout appears tied to the new shared search helper predicate being too strict around search API matching, and for the rest, the failures look out-of-scope to this PR (Glossary.spec.ts add-tag timeout, Users.spec.ts getApiContext reference error, lineage/user setup flakes like 409 already exists and user-list visibility polling). For the bot part, would you like me to proceed with relaxing the search API wait predicate in this branch? For the non-bot failures, should I keep this PR scoped and leave them for separate fixes, or do you want me to address them here as well?

[gitar-bot]

Code Review ✅ Approved 11 resolved / 11 findings

Bot name search is now optimized with direct lookups, a deduplicated enrichment process, and corrected result handling. These updates resolve N+1 API call patterns, race conditions, and pagination loops identified in the previous implementation.

✅ 11 resolved

✅ Edge Case: lodash lowerCase strips special chars, broadening search

📄 openmetadata-ui/src/main/resources/ui/src/utils/BotsUtils.tsx:90
The normalizeBotSearchValue helper uses lodash lowerCase, which doesn't just lowercase—it also splits on non-alphanumeric boundaries and joins with spaces. For example:

• lowerCase("ingestion-bot@example.com") → "ingestion bot example com"
• lowerCase("bot@") → "bot"

Because both the search term and bot fields are normalized the same way, matches are consistent (and the tests pass). However, this means searching for "bot@" will match any bot containing "bot" in any field, since the @ is silently dropped. For a bot admin page this is unlikely to cause real confusion, but if exact-substring matching is desired, value.toLowerCase() would be more precise while still being case-insensitive.

✅ Performance: N+1 API calls: getBotByName called individually per matched user

📄 openmetadata-ui/src/main/resources/ui/src/components/Settings/Bot/BotListV1/BotListV1.component.tsx:303-309
In searchBots, the inner getMatchedBots function calls getBotByName individually for each matched bot user name via Promise.allSettled. With pageSize: 100 on the search query, this could fire up to 100 sequential HTTP requests to the backend. While Promise.allSettled runs them concurrently, this still creates significant network overhead and backend load.

Since there's no batch bot-fetch API available, consider at minimum capping the number of concurrent requests (e.g., process in batches of 10) or reducing the pageSize to a more reasonable number. Alternatively, since the getBots API returns paginated results, you could fetch all bots (with pagination) and filter client-side for the search scenario, or propose a backend endpoint that accepts multiple names.

✅ Bug: Stale search results from race condition in handleSearch

📄 openmetadata-ui/src/main/resources/ui/src/components/Settings/Bot/BotListV1/BotListV1.component.tsx:383-397
Although the Searchbar component debounces input by 500ms, it's still possible for two debounced handleSearch calls to be in-flight simultaneously (e.g., user types, pauses 500ms, types again, pauses 500ms). Since handleSearch is async and there's no request cancellation, the first call could resolve after the second, overwriting correct results with stale data.

Consider adding a request ID or AbortController pattern to discard results from outdated searches.

✅ Quality: Duplicated bot-user enrichment logic in two functions

📄 openmetadata-ui/src/main/resources/ui/src/components/Settings/Bot/BotListV1/BotListV1.component.tsx:127-141 📄 openmetadata-ui/src/main/resources/ui/src/components/Settings/Bot/BotListV1/BotListV1.component.tsx:328-339
The pattern of merging bot-user fields (id, name, displayName, fullyQualifiedName, email) onto a Bot entity is duplicated between enrichBotsWithBotUsers (lines 127-145) and getMatchedBots (lines 328-339). If the enriched fields change, both locations must be updated in sync. Consider extracting a shared helper like mergeBotUser(bot: Bot, user: User): Bot.

✅ Performance: getBotsByBotUserNames scans all bots instead of direct lookup

📄 openmetadata-ui/src/main/resources/ui/src/components/Settings/Bot/BotListV1/BotListV1.component.tsx:154-168
The new getBotsByBotUserNames function paginates through ALL bots in the system (100 per page) to find a handful of matches by name. This replaces the previous N+1 getBotByName calls, but trades N individual targeted lookups for a full table scan that could require ceil(totalBots/100) API calls in the worst case.

For a system with 10,000 bots where a search matches 3 users, this function may issue ~100 paginated requests scanning every bot, when 3 direct getBotByName calls would suffice.

The early-exit optimization (remainingBotNames.size > 0) helps only if matched bots appear early in the pagination order.

...and 6 more resolved from earlier reviews

Options

Display: compact → Showing less information.

Comment with these commands to change:

Compact

gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[sonarqubecloud]

Quality Gate passed for 'open-metadata-ui'

Issues
1063 New issues
0 Accepted issues

Measures
17 Security Hotspots
0.0% Coverage on New Code
3.9% Duplication on New Code

See analysis details on SonarQube Cloud