Fixes #25878: listBots API does not return botUser field

[kratipaliwal]

Describe your changes:

Fixes #25878

GET /v1/bots (list) was never returning the botUser field, even when callers explicitly asked for it with ?fields=botUser. Existing GET /v1/bots/{id} and GET /v1/bots/name/{name} continued to return botUser as before.

Two independent bugs produced this:

1. BotResource did not expose a fields query parameter. list(), get(), and getByName() hardcoded "" for fields, so ?fields=botUser was silently ignored.
2. BotRepository only populated botUser via setFields (single-entity path). The list endpoint uses setFieldsInBulk → fetchAndSetFields, which dispatches through registered fieldFetchers. Combined with getFieldsStrippedFromStorageJson() stripping botUser from stored JSON, listed bots came back without it.

Fix

• BotResource: added a FIELDS = "botUser" constant and a @QueryParam("fields") on list, get, and getByName, forwarded to the internal handlers (previously the param was silently dropped).
• BotRepository: overrode setFieldsInBulk to batch-fetch botUser via relationshipDAO.findToBatch(..., CONTAINS, USER) when fields.contains("botUser"). Single-entity setFields remains unconditional to preserve backward compatibility for existing UI and SDK callers of GET /bots/{id} and GET /bots/name/{name}.

Final behavior

Endpoint	?fields not passed	?fields=botUser
GET /v1/bots/{id}	botUser returned (unchanged)	botUser returned
GET /v1/bots/name/{name}	botUser returned (unchanged)	botUser returned
GET /v1/bots (list)	botUser omitted	botUser returned

No breaking change for existing consumers of the single-entity GET endpoints. The list endpoint gains the missing ?fields=botUser support described in the Swagger docs.

Tests

Added regression integration tests in BotResourceIT covering the list, get, create, and patch paths:

• test_listBots_withoutFieldsParam_omitsBotUser — list without ?fields does not populate botUser.
• test_listBots_withFieldsParam_returnsBotUser — list with ?fields=botUser returns the relationship.
• test_listBots_multipleBots_allHaveBotUser — exercises the bulk-fetch code path with multiple bots.
• test_getBotById_alwaysReturnsBotUser / test_getBotByName_alwaysReturnsBotUser — backward-compat guards: single-entity GETs must continue to return botUser without ?fields.
• test_getBotById_withFieldsParam_returnsBotUser / test_getBotByName_withFieldsParam_returnsBotUser — explicit ?fields=botUser still works on single-entity GETs.
• test_createBot_responseIncludesBotUser — POST response continues to include botUser.
• test_patchBotDescription_preservesBotUser — patching description does not drop the botUser relationship.
• test_patchBot_cannotChangeBotUser — guards the immutability contract in restorePatchAttributes.

Type of change:

• Bug fix

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

---

Summary by Gitar

• API Improvements:
  • Added pagination parameters and fieldChanged filtering to the listVersions endpoint in BotResource.
• Test Infrastructure:
  • Implemented getVersionHistoryPaginated and getVersionHistoryWithFieldChanged in BotResourceIT to support verifying extended version history.

_{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!

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

[gitar-bot]

Code Review ✅ Approved 1 resolved / 1 findings

Updates the listBots API to correctly populate the botUser field, addressing the N+1 database lookup inefficiency during batch bot user fetching. No further issues found.

✅ 1 resolved

✅ Performance: batchFetchBotUsers still does N individual DB lookups per user

📄 openmetadata-service/src/main/java/org/openmetadata/service/jdbi3/BotRepository.java:88-94
The batchFetchBotUsers method correctly fetches all bot→user relationships in one query via findToBatch, but then calls Entity.getEntityReferenceById(Entity.USER, ...) inside the loop for each record (line 91-92). This results in N individual database queries to resolve each user entity reference, partially defeating the purpose of the batch optimization.

For small bot counts this is fine, but for large deployments the list endpoint could issue hundreds of individual queries.

Consider collecting all toId UUIDs first, then using a bulk fetch (e.g., Entity.getEntityReferencesByIds or a single IN-clause query) to resolve all user references in one round-trip.

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-ingestion'

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

🟡 Playwright Results — all passed (14 flaky)

✅ 3959 passed · ❌ 0 failed · 🟡 14 flaky · ⏭️ 86 skipped

Shard	Passed	Failed	Flaky	Skipped
🟡 Shard 1	298	0	1	4
🟡 Shard 2	754	0	5	8
🟡 Shard 3	731	0	1	7
🟡 Shard 4	757	0	2	18
🟡 Shard 5	686	0	1	41
🟡 Shard 6	733	0	4	8

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

• Pages/UserCreationWithPersona.spec.ts › Create user with persona and verify on profile (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 shows the actor who made the change (shard 2, 1 retry)
• Features/DomainFilterQueryFilter.spec.ts › Subdomain assets should be visible when parent domain is selected (shard 2, 1 retry)
• Features/Glossary/GlossaryHierarchy.spec.ts › should cancel move operation (shard 2, 1 retry)
• Features/Glossary/GlossaryWorkflow.spec.ts › should display correct status badge color and icon (shard 2, 1 retry)
• Features/RTL.spec.ts › Verify Following widget functionality (shard 3, 1 retry)
• Pages/DataContracts.spec.ts › Create Data Contract and validate for Pipeline (shard 4, 1 retry)
• Pages/DataContractsSemanticRules.spec.ts › Validate Owner Rule Is_Set (shard 4, 1 retry)
• Pages/EntityDataSteward.spec.ts › Tier Add, Update and Remove (shard 5, 1 retry)
• Pages/Glossary.spec.ts › Cancel glossary term delete operation (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/Users.spec.ts › Check permissions for Data Steward (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