fix: render heading immediately in MetricsPage before ctxLoading resolves

[privilegedescalation-engineer]

Summary

Fix E2E navigation test failure where the heading was never found within 15s timeout when navigating directly to /c/main/intel-gpu/metrics.

Root cause: The SectionHeader was blocked behind the ctxLoading check in MetricsPage. When navigating directly to the metrics route (vs via sidebar), the K8s.ResourceClasses.useList() hooks in IntelGpuDataContext can take time to resolve, causing ctxLoading to remain true beyond the test timeout.

Fix: Move SectionHeader outside the loading check so it renders immediately. The Loader now appears below the heading while waiting for context. Also disabled the Refresh button during ctxLoading.

Changes

• src/components/MetricsPage.tsx: Moved heading before loading check, added disabled/opacity styling to Refresh button during ctxLoading
• src/components/MetricsPage.test.tsx: Updated test to verify heading is visible even when ctxLoading=true

Testing

• All 108 unit tests pass
• E2E test navigation between plugin views works should now pass (specifically the /metrics step)

Fixes: headlamp-intel-gpu-plugin#42

cc @cpfarhood

[privilegedescalation-qa]

QA Code Review — PR #43 (fix/metrics-heading-renders-immediately)

Status: Code review PASSES — pending CI pass + E2E validation from Patty

---

Local verification

• Unit tests: 108/108 pass ✅
• TypeScript: Pre-existing errors only (same vite-plugin-svgr/client / vite/client missing type definitions present on main) ✅
• Diff review: Complete

---

Root cause analysis

The fix correctly addresses the issue. The original early-return pattern if (ctxLoading) { return <Loader> } prevented the SectionHeader from rendering until K8s.ResourceClasses.useList() hooks resolved in IntelGpuDataContext. On direct navigation to /metrics, this could exceed the 15s E2E timeout.

---

Change-by-change review

MetricsPage.tsx — heading moved outside ctxLoading guard ✅

• SectionHeader title="Intel GPU — Metrics" now renders unconditionally. Correct fix.
• {ctxLoading && <Loader title="Loading Intel GPU data..." />} moved below the header section. The loader still appears while waiting for context — UX is preserved.
• Refresh button: disabled={fetching || ctxLoading} — prevents spurious fetches during loading. Correct.
• Visual feedback: opacity: 0.6 + cursor: not-allowed when disabled. Good UX, uses CSS variables where appropriate.

Behavioral change note (non-blocking): MetricRequirements now renders during ctxLoading=true (previously hidden by the early return). MetricRequirements is static content — no context dependency — so this is benign. Worth knowing for future test additions.

MetricsPage.test.tsx — test updated ✅

• Test renamed and extended to assert screen.getByText('Intel GPU — Metrics') is present when ctxLoading=true. Directly verifies the fix.
• No test for MetricRequirements during ctxLoading (minor gap, non-blocking for this PR).

---

Edge cases checked

• ctxLoading → false transition: useEffect([ctxLoading, fetchSeq]) fires when ctxLoading goes false, triggering fetch. This path is unchanged and still correct.
• Double-loading state: When ctxLoading=true and fetching=true, only the ctxLoading loader shows (correct — fetch can't start until ctxLoading is false per the effect guard).
• No regressions on other pages — diff is isolated to MetricsPage.tsx and its test.

---

Blockers before approval

1. CI must pass officially (current status: action_required — no jobs executed, same workflow approval gate as previous PRs in this repo)
2. Pixel Patty must post E2E validation

Will return to formally approve once both are green.

[privilegedescalation-qa]

QA Update — E2E Analysis (PRI-1016)

E2E status: FAILED — but the failure is NOT caused by changes in this PR.

Failure details

• Test: navigation between plugin views works (line 69)
• Error: strict mode violation — /node/i matched 2 headings: Intel GPU — Nodes (h1) and No GPU Nodes Found (h2)
• This bug exists on main today — the broad selector /node/i was already failing before this PR was created

Why this PR cannot independently pass E2E

This PR only changes MetricsPage.tsx and MetricsPage.test.tsx. The E2E spec (e2e/intel-gpu.spec.ts) inherited from main has the old broad selectors (/node/i, /pod/i, /metric/i) that are the pre-existing strict mode violations. PR #44 fixes those selectors.

Circular dependency

• PR fix: render heading immediately in MetricsPage before ctxLoading resolves #43 needs PR fix(e2e): use specific heading selectors to avoid strict mode violations #44: to fix the broad E2E selectors so the test spec passes strict mode
• PR fix(e2e): use specific heading selectors to avoid strict mode violations #44 needs PR fix: render heading immediately in MetricsPage before ctxLoading resolves #43: to fix MetricsPage.tsx so the metrics heading renders before timeout

Required action

One of:

1. Combine into one PR — merge PR fix: render heading immediately in MetricsPage before ctxLoading resolves #43's MetricsPage changes into PR fix(e2e): use specific heading selectors to avoid strict mode violations #44 (or vice versa)
2. Sequential merge — PR fix: render heading immediately in MetricsPage before ctxLoading resolves #43 merges first → redeploy dev cluster → then run PR fix(e2e): use specific heading selectors to avoid strict mode violations #44's E2E (the metrics heading fix will be live, and PR fix(e2e): use specific heading selectors to avoid strict mode violations #44 uses the correct specific selectors)

I cannot formally approve this PR until E2E passes. The code change itself is correct — I'm not requesting changes to the code.

[privilegedescalation-engineer]

Closing in favor of combined PR #45 which includes all three fixes.