perf(ui): fetch entity in parallel with permission on 3 more detail pages (W1 rollout)

[harsh-vador]

Description

Applies the DatabaseDetailsPage template (#30867) to the other react-query permission-gated detail pages. Each entity useQuery was enabled only after the permission fetch resolved (enabled: ...viewPermission && !permissionsLoading), forcing two serial round-trips on mount. Each now fires the GET in parallel with the permission fetch.

• SearchIndexDetailsPage — enabled gated on FQN only. Render already checks !viewPermission before the error state and there is no forbidden redirect, so no other change is needed.
• StoredProcedurePage — enabled gated on FQN only; the /forbidden redirect now fires only on a genuine permission desync (viewBasicPermission true), so a no-permission user falls through to the inline PERMISSION placeholder.
• APICollectionPage — enabled gated on FQN only; the 403 branch is nested so a no-permission 403 redirects only on desync and never falls through to the error toast. Render already checks permission before isError.

Type of change

• Performance (request waterfall → parallel)

Tests

• Updated the two tests that asserted the old "no permission ⇒ no fetch" waterfall behaviour to assert the new intended behaviour: the fetch fires in parallel and render still gates on permission (placeholder shown).
• All 16 unit tests across the three pages pass; eslint clean.

Verification note

Same as the template — the 403 / permission UX is best also confirmed in a running app / Playwright (Jest mocks permissions, not the real backend 403). Check: happy path loads; a no-permission user sees the inline placeholder and is not redirected to /forbidden.

Ref: open-metadata/openmetadata-collate#5442

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

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

🔴 Playwright Results — workflow failed

Validated commit 4e2998b85993b706bafd1145d830690e00187ecc in Playwright run 30806346926, attempt 1.

✅ 0 passed · ❌ 0 failed · 🟡 0 flaky · ⏭️ 0 skipped · 🧰 0 lifecycle flaky

Pipeline and setup failures (6)

• The build job finished with status failure.
• Duration-aware shard planning finished with status skipped.
• Fixture cache restoration finished with status skipped.
• Seeded fixture preparation finished with status skipped.
• The Playwright shard matrix was unexpectedly skipped.
• No expected Playwright shards were declared.

Performance

⚪ Performance metrics unavailable; see the CI and reporting failures above.

Shard	Passed	Failed	Flaky	Skipped	Lifecycle failed	Lifecycle flaky

📦 Download artifacts

How to debug locally

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

[gitar-bot]

Code Review 👍 Approved with suggestions 0 resolved / 1 findings

Fetches entity data in parallel with permissions across SearchIndexDetailsPage, StoredProcedurePage, and APICollectionPage to eliminate request waterfalls. Consider refining the loading states to prevent no-permission users from seeing a loader before the permission placeholder.

💡 Edge Case: No-permission users now see a loader before the placeholder

📄 openmetadata-ui/src/main/resources/ui/src/pages/SearchIndexDetailsPage/SearchIndexDetailsPage.tsx 📄 openmetadata-ui/src/main/resources/ui/src/pages/StoredProcedure/StoredProcedurePage.tsx

In SearchIndexDetailsPage (if (isLoading || permissionsLoading || searchIndexLoading)) and StoredProcedurePage (if (permissionsLoading || loading || storedProcedureLoading)), the loading gate includes the entity query's isLoading. Previously the entity query was disabled for no-permission users so isLoading was always false and the PERMISSION placeholder showed immediately once permission resolved. Now that the query is enabled on FQN only, a no-permission user sees a loading spinner until the backend 403 returns, then the placeholder — an extra loading flash. Note APICollectionPage avoids this because its gate (if (isPermissionsLoading || isLoading)) does not include the entity isLoading. Consider dropping the entity loading flag from the gate (or OR-ing in !viewPermission) so the placeholder shows as soon as permission resolves, keeping behavior consistent across the three pages.

🤖 Prompt for agents

Code Review: Fetches entity data in parallel with permissions across SearchIndexDetailsPage, StoredProcedurePage, and APICollectionPage to eliminate request waterfalls. Consider refining the loading states to prevent no-permission users from seeing a loader before the permission placeholder.

1. 💡 Edge Case: No-permission users now see a loader before the placeholder
   Files: openmetadata-ui/src/main/resources/ui/src/pages/SearchIndexDetailsPage/SearchIndexDetailsPage.tsx, openmetadata-ui/src/main/resources/ui/src/pages/StoredProcedure/StoredProcedurePage.tsx

   In SearchIndexDetailsPage (`if (isLoading || permissionsLoading || searchIndexLoading)`) and StoredProcedurePage (`if (permissionsLoading || loading || storedProcedureLoading)`), the loading gate includes the entity query's `isLoading`. Previously the entity query was disabled for no-permission users so `isLoading` was always false and the PERMISSION placeholder showed immediately once permission resolved. Now that the query is enabled on FQN only, a no-permission user sees a loading spinner until the backend 403 returns, then the placeholder — an extra loading flash. Note APICollectionPage avoids this because its gate (`if (isPermissionsLoading || isLoading)`) does not include the entity `isLoading`. Consider dropping the entity loading flag from the gate (or OR-ing in `!viewPermission`) so the placeholder shows as soon as permission resolves, keeping behavior consistent across the three pages.

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}