OCPBUGS-86894: reduce startup API calls and prioritize critical fetches

[logonoff]

Analysis / Root cause:

Profiling startup network activity revealed that the useUser hook (which fetches users/~ from the k8s API) uses useK8sGet — a hook with no cross-instance deduplication. Every component that calls useUser() (directly or via useTelemetry()) triggers an independent fetch. With ~10+ component instances mounting during startup, this produced 22 duplicate API calls to the same endpoint.

Additionally, the 3 MB openapi/v2 fetch and multiple terminal/available checks were competing with critical startup resources for bandwidth, with no fetch priority hints to let the browser schedule them appropriately.

Solution description:

1. useUser: Switch from useK8sGet to useK8sWatchResource, which deduplicates at the Redux/watch infrastructure level. All hook instances share a single underlying watch, reducing users/~ calls from 22 to 1. This also correctly handles impersonation changes since the watch infrastructure reconnects when auth context changes.

2. Fetch Priority hints (Fetch Priority API):

   • priority: 'high' on the early auth check (api/kubernetes/api) so the browser prioritizes the authentication redirect check
   • priority: 'low' on openapi/v2 (3 MB, used only for form field descriptions — not needed for initial render)
   • priority: 'low' on terminal/available checks (not render-critical)

3. Remove duplicate fetchSwagger call from actions/k8s.ts — app.tsx already handles the initial fetch and 5-minute polling, so the second call 10 seconds after discovery was redundant.

Performance results

Tested under simulated Fast 3G (1.5 Mbps, 562ms RTT) + 4x CPU throttle, 5 runs each, browser cache cleared between runs. App-ready measured as time until [data-test="page-heading"] h1 is visible.

Metric	Before (main)	After (this PR)	Improvement
App ready (median)	37.0s	29.8s	-7.1s (19% faster)
App ready (avg)	36.2s	29.2s	-7.0s (19% faster)
Total API calls	73	47	-26 calls (36% fewer)
Total resources loaded	134	107	-27 resources (20% fewer)
users/~ calls	22	1	-21 calls
terminal/available calls	8	3	-5 calls
Total transfer	2,974 KB	2,933 KB	-41 KB

Screenshots / screen recording:

Test setup:

Two console instances running against the same cluster:

• :9000 — this PR (OCPBUGS-86894-useuser branch)
• :9001 — HEAD of main

Both running over HTTP/1.1 with auth disabled, localhost bridge, same OCP 5.0 cluster.

Benchmarked with Playwright using Chrome DevTools Protocol for CPU/network throttling.

Test cases:

• Verified users/~ is fetched exactly once during startup (was 22x)
• Verified terminal/available uses priority: 'low' and yields to critical resources
• Verified openapi/v2 uses priority: 'low' and downloads after critical resources
• Verified impersonation still works correctly (useK8sWatchResource reconnects on auth change)
• Verified the app renders the same UI with all features functional
• Impersonation still works
• yarn test passes

Browser conformance:

• Chrome
• Firefox
• Safari (or Epiphany on Linux)

Additional info:

The useK8sGet hook creates a new useState + useEffect per instance with no shared state — every component that mounts independently fetches the same resource. useK8sWatchResource uses the console's watch infrastructure which deduplicates at the Redux store level, so multiple hook instances share a single underlying fetch/watch.

The Fetch Priority API (priority: 'low' / 'high') is supported in Chrome 101+, Edge 101+, and Safari 17.2+. Unsupported browsers silently ignore the hint with no behavioral change.

Summary by CodeRabbit

• Performance Improvements

  • Early auth API request is now prioritized; OpenAPI/Swagger fetches moved to low‑priority/background.

• Updates

  • User data now syncs via a watch-based mechanism for more timely updates.
  • Terminal availability checks use lower‑priority network requests.

• UI / UX

  • New auth‑pending skeleton, slow‑loading message with a refresh action, updated loading fallback, and two new English strings.

• Tests

  • Updated tests to reflect watch-based user loading and related behaviors.

[openshift-ci-robot]

@logonoff: This pull request references Jira Issue OCPBUGS-86894, which is valid. The bug has been moved to the POST state.

3 validation(s) were run on this bug

• bug is open, matching expected state (open)
• bug target version (5.0.0) matches configured target version for branch (5.0.0)
• bug is in the state New, which is one of the valid states (NEW, ASSIGNED, POST)

The bug has been updated to refer to the pull request using the external bug tracker.

Details

In response to this:

Analysis / Root cause:

Profiling startup network activity revealed that the useUser hook (which fetches users/~ from the k8s API) uses useK8sGet — a hook with no cross-instance deduplication. Every component that calls useUser() (directly or via useTelemetry()) triggers an independent fetch. With ~10+ component instances mounting during startup, this produced 22 duplicate API calls to the same endpoint.

Additionally, the 3 MB openapi/v2 fetch and multiple terminal/available checks were competing with critical startup resources for bandwidth, with no fetch priority hints to let the browser schedule them appropriately.

Solution description:

1. useUser: Switch from useK8sGet to useK8sWatchResource, which deduplicates at the Redux/watch infrastructure level. All hook instances share a single underlying watch, reducing users/~ calls from 22 to 1. This also correctly handles impersonation changes since the watch infrastructure reconnects when auth context changes.

2. Fetch Priority hints (Fetch Priority API):

• priority: 'high' on the early auth check (api/kubernetes/api) so the browser prioritizes the authentication redirect check
• priority: 'low' on openapi/v2 (3 MB, used only for form field descriptions — not needed for initial render)
• priority: 'low' on terminal/available checks (not render-critical)

3. Remove duplicate fetchSwagger call from actions/k8s.ts — app.tsx already handles the initial fetch and 5-minute polling, so the second call 10 seconds after discovery was redundant.

Performance results

Tested under simulated Fast 3G (1.5 Mbps, 562ms RTT) + 4x CPU throttle, 5 runs each, browser cache cleared between runs. App-ready measured as time until [data-test="page-heading"] h1 is visible.

Metric	Before (main)	After (this PR)	Improvement
App ready (median)	37.0s	29.8s	-7.1s (19% faster)
App ready (avg)	36.2s	29.2s	-7.0s (19% faster)
Total API calls	73	47	-26 calls (36% fewer)
Total resources loaded	134	107	-27 resources (20% fewer)
users/~ calls	22	1	-21 calls
terminal/available calls	8	3	-5 calls
Total transfer	2,974 KB	2,933 KB	-41 KB

Screenshots / screen recording:

Test setup:

Two console instances running against the same cluster:

• :9000 — this PR (OCPBUGS-86894-useuser branch)
• :9001 — HEAD of main

Both running over HTTP/1.1 with auth disabled, localhost bridge, same OCP 5.0 cluster.

Benchmarked with Playwright using Chrome DevTools Protocol for CPU/network throttling.

Test cases:

• Verified users/~ is fetched exactly once during startup (was 22x)
• Verified terminal/available uses priority: 'low' and yields to critical resources
• Verified openapi/v2 uses priority: 'low' and downloads after critical resources
• Verified impersonation still works correctly (useK8sWatchResource reconnects on auth change)
• Verified the app renders the same UI with all features functional
• yarn test passes

Browser conformance:

• Chrome
• Firefox
• Safari (or Epiphany on Linux)

Additional info:

The useK8sGet hook creates a new useState + useEffect per instance with no shared state — every component that mounts independently fetches the same resource. useK8sWatchResource uses the console's watch infrastructure which deduplicates at the Redux store level, so multiple hook instances share a single underlying fetch/watch.

The Fetch Priority API (priority: 'low' / 'high') is supported in Chrome 101+, Edge 101+, and Safari 17.2+. Unsupported browsers silently ignore the hint with no behavioral change.

Reviewers and assignees:

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@logonoff: This pull request references Jira Issue OCPBUGS-86894, which is valid.

3 validation(s) were run on this bug

• bug is open, matching expected state (open)
• bug target version (5.0.0) matches configured target version for branch (5.0.0)
• bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, POST)

Details

In response to this:

Analysis / Root cause:

Profiling startup network activity revealed that the useUser hook (which fetches users/~ from the k8s API) uses useK8sGet — a hook with no cross-instance deduplication. Every component that calls useUser() (directly or via useTelemetry()) triggers an independent fetch. With ~10+ component instances mounting during startup, this produced 22 duplicate API calls to the same endpoint.

Additionally, the 3 MB openapi/v2 fetch and multiple terminal/available checks were competing with critical startup resources for bandwidth, with no fetch priority hints to let the browser schedule them appropriately.

Solution description:

1. useUser: Switch from useK8sGet to useK8sWatchResource, which deduplicates at the Redux/watch infrastructure level. All hook instances share a single underlying watch, reducing users/~ calls from 22 to 1. This also correctly handles impersonation changes since the watch infrastructure reconnects when auth context changes.

2. Fetch Priority hints (Fetch Priority API):

• priority: 'high' on the early auth check (api/kubernetes/api) so the browser prioritizes the authentication redirect check
• priority: 'low' on openapi/v2 (3 MB, used only for form field descriptions — not needed for initial render)
• priority: 'low' on terminal/available checks (not render-critical)

3. Remove duplicate fetchSwagger call from actions/k8s.ts — app.tsx already handles the initial fetch and 5-minute polling, so the second call 10 seconds after discovery was redundant.

Performance results

Tested under simulated Fast 3G (1.5 Mbps, 562ms RTT) + 4x CPU throttle, 5 runs each, browser cache cleared between runs. App-ready measured as time until [data-test="page-heading"] h1 is visible.

Metric	Before (main)	After (this PR)	Improvement
App ready (median)	37.0s	29.8s	-7.1s (19% faster)
App ready (avg)	36.2s	29.2s	-7.0s (19% faster)
Total API calls	73	47	-26 calls (36% fewer)
Total resources loaded	134	107	-27 resources (20% fewer)
users/~ calls	22	1	-21 calls
terminal/available calls	8	3	-5 calls
Total transfer	2,974 KB	2,933 KB	-41 KB

Screenshots / screen recording:

Test setup:

Two console instances running against the same cluster:

• :9000 — this PR (OCPBUGS-86894-useuser branch)
• :9001 — HEAD of main

Both running over HTTP/1.1 with auth disabled, localhost bridge, same OCP 5.0 cluster.

Benchmarked with Playwright using Chrome DevTools Protocol for CPU/network throttling.

Test cases:

• Verified users/~ is fetched exactly once during startup (was 22x)
• Verified terminal/available uses priority: 'low' and yields to critical resources
• Verified openapi/v2 uses priority: 'low' and downloads after critical resources
• Verified impersonation still works correctly (useK8sWatchResource reconnects on auth change)
• Verified the app renders the same UI with all features functional
• yarn test passes

Browser conformance:

• Chrome
• Firefox
• Safari (or Epiphany on Linux)

Additional info:

The useK8sGet hook creates a new useState + useEffect per instance with no shared state — every component that mounts independently fetches the same resource. useK8sWatchResource uses the console's watch infrastructure which deduplicates at the Redux store level, so multiple hook instances share a single underlying fetch/watch.

The Fetch Priority API (priority: 'low' / 'high') is supported in Chrome 101+, Edge 101+, and Safari 17.2+. Unsupported browsers silently ignore the hint with no behavioral change.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

Walkthrough

User resource loading now uses a stable watch descriptor; coFetch calls gain explicit priorities (high for early auth, low for deferred Swagger/terminal checks); delayed post-resource Swagger scheduling was removed; an auth-pending skeleton, translations, and styles were added.

Changes

User resource watch update

Layer / File(s)	Summary
useUser watch implementation frontend/packages/console-shared/src/hooks/useUser.ts	useUser switches from a one-time Kubernetes get to useK8sWatchResource with a static userWatchResource descriptor; it reads watched data and conditionally dispatches setUserResource.
useUser tests and mock updates frontend/packages/console-shared/src/hooks/__tests__/useUser.spec.ts	Tests now mock useK8sWatchResource instead of useK8sGet, update displayName assertions, add referential-equality test for the watch descriptor, and verify Redux dispatch on watched updates after impersonation state changes.

Fetch Request Handling and Prioritization

Layer / File(s)	Summary
fetchSwagger priority and tests frontend/public/module/k8s/swagger.ts, frontend/public/module/k8s/__tests__/swagger.spec.ts	fetchSwagger calls coFetch with { priority: 'low' }; tests updated to expect the priority option in relevant assertions.
App early auth and actions change frontend/public/components/app.tsx, frontend/public/actions/k8s.ts	Early authenticated Kubernetes fetch now uses { priority: 'high' } and explicitly swallows errors; resource action no longer schedules a delayed fetchSwagger() call.
Terminal availability check priority frontend/packages/webterminal-plugin/src/components/cloud-shell/cloud-shell-utils.ts	checkTerminalAvailable now calls /api/terminal/available via coFetch with { priority: 'low' }.

Auth-pending skeleton, translations, and styles

Layer / File(s)	Summary
DetectContext slow-loading UI frontend/packages/console-app/src/components/detect-context/DetectContext.tsx	Adds SlowLoadingMessage, local PageSkeleton wrapping LoadingBox, i18n usage, and additional PatternFly imports for the slow-loading UI.
Auth-pending styles, HTML, and locales frontend/public/style/_layout.scss, frontend/public/index.html, frontend/public/locales/en/public.json, frontend/public/components/cluster-settings/_cluster-settings.scss	Adds .co-auth-pending-driven skeleton state and animations, updates <html> classes with co-auth-pending, adds two public translation keys, and reorders one SCSS declaration in cluster-settings.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• openshift/console#16457: Modifies fetchSwagger in the same frontend/public/module/k8s/swagger.ts file with overlapping changes to coFetch request behavior for OpenAPI v2 retrieval.

Suggested labels

verified

Suggested reviewers

• TheRealJon
• Leo6Leo

🚥 Pre-merge checks | ✅ 15

✅ Passed checks (15 passed)

Check name	Status	Explanation
Title check	✅ Passed	The PR title clearly and specifically summarizes the main changes: reducing startup API calls and prioritizing critical fetches using the Fetch Priority API.
Description check	✅ Passed	The PR description includes all required template sections: analysis/root cause, solution description, test setup, test cases, and browser conformance. The description is comprehensive with performance metrics and technical rationale.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Stable And Deterministic Test Names	✅ Passed	No Ginkgo tests found in PR. Changes only affect TypeScript/Jest tests (useUser.spec.ts, swagger.spec.ts) with stable, deterministic test names containing no dynamic information.
Test Structure And Quality	✅ Passed	Custom check is for Ginkgo test code quality, but PR contains only Jest tests (JavaScript/TypeScript). No Ginkgo tests exist in PR; check is not applicable.
Microshift Test Compatibility	✅ Passed	PR contains no new Ginkgo e2e tests—only frontend TypeScript/React code and Jest unit tests. MicroShift compatibility check is not applicable.
Single Node Openshift (Sno) Test Compatibility	✅ Passed	No Ginkgo e2e tests are added in this PR. The changes are entirely frontend/console UI and performance optimizations; test file modifications are Jest unit tests only.
Topology-Aware Scheduling Compatibility	✅ Passed	PR contains only frontend code (React, SCSS, HTML, JSON) with no deployment manifests or operator code, so topology-aware scheduling check is not applicable.
Ote Binary Stdout Contract	✅ Passed	PR contains only frontend TypeScript/SCSS/HTML changes; no Go test suite setup code or process-level stdout writes introduced; OTE Binary Stdout Contract check is not applicable.
Ipv6 And Disconnected Network Test Compatibility	✅ Passed	This PR contains only frontend TypeScript/JavaScript code changes with Jest unit tests; no Ginkgo e2e tests are added, so the IPv6/disconnected environment compatibility check does not apply.
No-Weak-Crypto	✅ Passed	No weak cryptographic algorithms (MD5, SHA1, DES, RC4, 3DES, Blowfish, ECB), custom crypto implementations, or insecure secret comparisons introduced in PR changes.
Container-Privileges	✅ Passed	PR contains no Kubernetes manifests, container configs, or Dockerfiles; no privileged settings found. Check not applicable to frontend-only performance optimization PR.
No-Sensitive-Data-In-Logs	✅ Passed	No NEW logging exposing sensitive data introduced. All logging found is pre-existing error handling; PR removes fetchSwagger logging.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Leo6Leo]

Review and prowpy retest monitoring
/assign @Leo6Leo

[coderabbitai]

🧹 Nitpick comments (1)

frontend/packages/console-shared/src/hooks/__tests__/useUser.spec.ts (1)

81-95: ⚡ Quick win

Add coverage for the watch-error path.

useUser only dispatches setUserResource when userResourceLoaded && userResourceData && !userResourceError. The new tests cover the success and impersonation cases, but there's no test asserting that a watch error (e.g. [null, true, someError]) suppresses the dispatch. That branch is the most likely to regress silently.

💚 Suggested test to cover the error branch

+ it('should not dispatch setUserResource when the watch reports an error', () => {+ const mockUser = { username: 'testuser@example.com' };++ mockUseSelector.mockReturnValueOnce(mockUser).mockReturnValueOnce(null);+ mockUseK8sWatchResource.mockReturnValue([null, true, new Error('forbidden')]);++ renderHook(() => useUser());++ expect(mockDispatch).not.toHaveBeenCalled();+ });

Want me to open an issue to track this coverage gap?

Also applies to: 152-167

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@frontend/packages/console-shared/src/hooks/__tests__/useUser.spec.ts` around
lines 81 - 95, Add a test in useUser.spec.ts to cover the watch-error branch by
simulating useUser with an existing user (mockUseSelector returns the user) and
mockUseK8sWatchResource returning [null, true, someError] (i.e.,
userResourceLoaded true but userResourceError present), then renderHook(() =>
useUser()) and assert that mockDispatch was NOT called with the setUserResource
action (type 'setUserResource', payload { userResource: ... }); this ensures
useUser's conditional (userResourceLoaded && userResourceData &&
!userResourceError) correctly suppresses dispatch on watch errors.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@frontend/packages/console-shared/src/hooks/__tests__/useUser.spec.ts`:
- Around line 81-95: Add a test in useUser.spec.ts to cover the watch-error
branch by simulating useUser with an existing user (mockUseSelector returns the
user) and mockUseK8sWatchResource returning [null, true, someError] (i.e.,
userResourceLoaded true but userResourceError present), then renderHook(() =>
useUser()) and assert that mockDispatch was NOT called with the setUserResource
action (type 'setUserResource', payload { userResource: ... }); this ensures
useUser's conditional (userResourceLoaded && userResourceData &&
!userResourceError) correctly suppresses dispatch on watch errors.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository: openshift/coderabbit/.coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: a2cb42c1-2fff-4d38-b16b-71173bd47241

📥 Commits

Reviewing files that changed from the base of the PR and between 7e6f324 and 3d08b43.

📒 Files selected for processing (7)

• frontend/packages/console-shared/src/hooks/__tests__/useUser.spec.ts
• frontend/packages/console-shared/src/hooks/useUser.ts
• frontend/packages/webterminal-plugin/src/components/cloud-shell/cloud-shell-utils.ts
• frontend/public/actions/k8s.ts
• frontend/public/components/app.tsx
• frontend/public/module/k8s/__tests__/swagger.spec.ts
• frontend/public/module/k8s/swagger.ts

✅ Files skipped from review due to trivial changes (2)

• frontend/packages/webterminal-plugin/src/components/cloud-shell/cloud-shell-utils.ts
• frontend/public/module/k8s/tests/swagger.spec.ts

🚧 Files skipped from review as they are similar to previous changes (4)

• frontend/public/components/app.tsx
• frontend/packages/console-shared/src/hooks/useUser.ts
• frontend/public/actions/k8s.ts
• frontend/public/module/k8s/swagger.ts

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@frontend/public/components/app.tsx`:
- Around line 88-92: The probe currently removes the co-auth-pending class only
on success (coFetch(...).then(() =>
document.documentElement.classList.remove('co-auth-pending'))), and swallows
errors in catch, leaving the class set on failures; update the promise handling
for coFetch to ensure
document.documentElement.classList.remove('co-auth-pending') runs on both
success and failure (use a .finally() or call the same remove in both .then and
.catch) and keep the catch logic for any error handling/logging as needed so the
class is always cleared.
In `@frontend/public/style/_layout.scss`:
- Around line 42-52: The reduced-motion media query currently only sets
animation-duration to 0s but leaves the 20s animation delay on
.co-page-skeleton__slow-msg, so update the `@media` (prefers-reduced-motion:
reduce) block to also cancel the delay (e.g., set animation: none or set
animation-delay: 0s in addition to animation-duration: 0s) for the
.co-page-skeleton__slow-msg selector to ensure the recovery hint appears
immediately for users who prefer reduced motion.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository: openshift/coderabbit/.coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: 692edb77-4ee9-4122-8703-6931a22e739e

📥 Commits

Reviewing files that changed from the base of the PR and between bfa581e and aecb812.

📒 Files selected for processing (12)

• frontend/packages/console-app/src/components/detect-context/DetectContext.tsx
• frontend/packages/console-shared/src/hooks/__tests__/useUser.spec.ts
• frontend/packages/console-shared/src/hooks/useUser.ts
• frontend/packages/webterminal-plugin/src/components/cloud-shell/cloud-shell-utils.ts
• frontend/public/actions/k8s.ts
• frontend/public/components/app.tsx
• frontend/public/components/cluster-settings/_cluster-settings.scss
• frontend/public/index.html
• frontend/public/locales/en/public.json
• frontend/public/module/k8s/__tests__/swagger.spec.ts
• frontend/public/module/k8s/swagger.ts
• frontend/public/style/_layout.scss

✅ Files skipped from review due to trivial changes (3)

• frontend/public/components/cluster-settings/_cluster-settings.scss
• frontend/public/module/k8s/swagger.ts
• frontend/packages/webterminal-plugin/src/components/cloud-shell/cloud-shell-utils.ts

🚧 Files skipped from review as they are similar to previous changes (4)

• frontend/public/actions/k8s.ts
• frontend/packages/console-shared/src/hooks/useUser.ts
• frontend/public/module/k8s/tests/swagger.spec.ts
• frontend/packages/console-shared/src/hooks/tests/useUser.spec.ts

[logonoff]

QA Verification Evidence

	Details
Branch	OCPBUGS-86894-useuser
Baseline	main @ 9459497c24
Candidate	OCPBUGS-86894-useuser @ 01d38ea7a3
Verified	2026-06-08
Browser	Playwright 1.60.0 / Chrome for Testing 148.0.7778.96 (playwright chromium v1223)
OS	Darwin 25.5.0
Jira	OCPBUGS-86894

Verification Steps

#	Route	Action	Status
number	route	action	status
1	/dashboards	Navigate, wait for load	pass
2	/settings/cluster	Navigate to cluster settings	pass
3	/k8s/cluster/nodes	Navigate to nodes list	pass
4	/k8s/ns/openshift-console/pods	Navigate to pods list	pass
5	/k8s/ns/openshift-console/deployments	Navigate to deployments	pass
6	(all pages)	Check console errors	pass

Animated overview (click to expand)

Baseline	Candidate

Step 1: description (status)

Baseline (main)	Candidate (OCPBUGS-86894-useuser)

Step 2: Dashboard overview (pass)

Baseline (main)	Candidate (OCPBUGS-86894-useuser)

Step 3: Cluster settings page (SCSS change) (pass)

Baseline (main)	Candidate (OCPBUGS-86894-useuser)

Step 4: Nodes list (user context) (pass)

Baseline (main)	Candidate (OCPBUGS-86894-useuser)

Step 5: Pods in openshift-console (pass)

Baseline (main)	Candidate (OCPBUGS-86894-useuser)

---

Warning

This verification was performed by an AI agent. Results may contain false positives or miss
regressions that require human judgment. Always review the screenshots manually before approving.

Automated QA verification by Claude Code

[logonoff]

/verified by @logonoff

[openshift-ci-robot]

@logonoff: This PR has been marked as verified by @logonoff.

Details

In response to this:

/verified by @logonoff

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci]

@logonoff: all tests passed!

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[Leo6Leo]

/lgtm

[openshift-ci-robot]

@logonoff: Jira Issue Verification Checks: Jira Issue OCPBUGS-86894
✔️ This pull request was pre-merge verified.
✔️ All associated pull requests have merged.
✔️ All associated, merged pull requests were pre-merge verified.

Jira Issue OCPBUGS-86894 has been moved to the MODIFIED state and will move to the VERIFIED state when the change is available in an accepted nightly payload. 🕓

Details

In response to this:

Analysis / Root cause:

Profiling startup network activity revealed that the useUser hook (which fetches users/~ from the k8s API) uses useK8sGet — a hook with no cross-instance deduplication. Every component that calls useUser() (directly or via useTelemetry()) triggers an independent fetch. With ~10+ component instances mounting during startup, this produced 22 duplicate API calls to the same endpoint.

Additionally, the 3 MB openapi/v2 fetch and multiple terminal/available checks were competing with critical startup resources for bandwidth, with no fetch priority hints to let the browser schedule them appropriately.

Solution description:

1. useUser: Switch from useK8sGet to useK8sWatchResource, which deduplicates at the Redux/watch infrastructure level. All hook instances share a single underlying watch, reducing users/~ calls from 22 to 1. This also correctly handles impersonation changes since the watch infrastructure reconnects when auth context changes.

2. Fetch Priority hints (Fetch Priority API):

• priority: 'high' on the early auth check (api/kubernetes/api) so the browser prioritizes the authentication redirect check
• priority: 'low' on openapi/v2 (3 MB, used only for form field descriptions — not needed for initial render)
• priority: 'low' on terminal/available checks (not render-critical)

3. Remove duplicate fetchSwagger call from actions/k8s.ts — app.tsx already handles the initial fetch and 5-minute polling, so the second call 10 seconds after discovery was redundant.

Performance results

Tested under simulated Fast 3G (1.5 Mbps, 562ms RTT) + 4x CPU throttle, 5 runs each, browser cache cleared between runs. App-ready measured as time until [data-test="page-heading"] h1 is visible.

Metric	Before (main)	After (this PR)	Improvement
App ready (median)	37.0s	29.8s	-7.1s (19% faster)
App ready (avg)	36.2s	29.2s	-7.0s (19% faster)
Total API calls	73	47	-26 calls (36% fewer)
Total resources loaded	134	107	-27 resources (20% fewer)
users/~ calls	22	1	-21 calls
terminal/available calls	8	3	-5 calls
Total transfer	2,974 KB	2,933 KB	-41 KB

Screenshots / screen recording:

Test setup:

Two console instances running against the same cluster:

• :9000 — this PR (OCPBUGS-86894-useuser branch)
• :9001 — HEAD of main

Both running over HTTP/1.1 with auth disabled, localhost bridge, same OCP 5.0 cluster.

Benchmarked with Playwright using Chrome DevTools Protocol for CPU/network throttling.

Test cases:

• Verified users/~ is fetched exactly once during startup (was 22x)
• Verified terminal/available uses priority: 'low' and yields to critical resources
• Verified openapi/v2 uses priority: 'low' and downloads after critical resources
• Verified impersonation still works correctly (useK8sWatchResource reconnects on auth change)
• Verified the app renders the same UI with all features functional
• Impersonation still works
• yarn test passes

Browser conformance:

• Chrome
• Firefox
• Safari (or Epiphany on Linux)

Additional info:

The useK8sGet hook creates a new useState + useEffect per instance with no shared state — every component that mounts independently fetches the same resource. useK8sWatchResource uses the console's watch infrastructure which deduplicates at the Redux store level, so multiple hook instances share a single underlying fetch/watch.

The Fetch Priority API (priority: 'low' / 'high') is supported in Chrome 101+, Edge 101+, and Safari 17.2+. Unsupported browsers silently ignore the hint with no behavioral change.

Summary by CodeRabbit

• Performance Improvements

• Early auth API request is now prioritized; OpenAPI/Swagger fetches moved to low‑priority/background.

• Updates

• User data now syncs via a watch-based mechanism for more timely updates.

• Terminal availability checks use lower‑priority network requests.

• UI / UX

• New auth‑pending skeleton, slow‑loading message with a refresh action, updated loading fallback, and two new English strings.

• Tests

• Updated tests to reflect watch-based user loading and related behaviors.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Leo6Leo, logonoff, vojtechszocs

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• frontend/OWNERS [logonoff,vojtechszocs]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-merge-robot]

Fix included in release 5.0.0-0.nightly-2026-06-10-003138