Skip to content

A workbench cannot be stopped if it's hardware profile doesn't exist - #6947

Merged
openshift-merge-bot[bot] merged 3 commits into
opendatahub-io:stable-2.xfrom
srtanish1992:bug/RHOAIENG-50913
Mar 30, 2026
Merged

A workbench cannot be stopped if it's hardware profile doesn't exist#6947
openshift-merge-bot[bot] merged 3 commits into
opendatahub-io:stable-2.xfrom
srtanish1992:bug/RHOAIENG-50913

Conversation

@srtanish1992

@srtanish1992 srtanish1992 commented Mar 27, 2026

Copy link
Copy Markdown
Contributor

JIRA ticket - https://redhat.atlassian.net/browse/RHOAIENG-50913

Testing instructions and more details in #5392

From Claude:

The changes aren't identical because stable-2.x has diverged significantly from main where PR #5392 was originally merged. During conflict resolution, I had to adapt the code to fit the stable-2.x codebase. Here are the specific differences and why each was necessary:

  1. startNotebook keeps tolerationChanges parameter On main, a separate prior PR removed tolerationChanges from startNotebook. On stable-2.x, it still exists. So the backport keeps tolerationChanges AND adds extraPatches (4 params instead of 3).

  2. const.ts includes HardwareProfileBindingState enum On main, this enum already existed before PR On notebook start/stop, remove hwp annotations from notebook when hwp is deleted #5392 (added by a different PR). On stable-2.x, it doesn't exist. I had to add it because useHardwareProfileBindingState.ts and getDeletedHardwareProfilePatches depend on it. I omitted HARDWARE_PROFILE_BINDING_CONFIG and HARDWARE_PROFILE_SELECTION_HELP since they're not needed for the fix.

  3. types.ts includes HardwareProfileBindingStateInfo type Same situation — this type existed on main before PR On notebook start/stop, remove hwp annotations from notebook when hwp is deleted #5392 but doesn't exist on stable-2.x. Added as a dependency.

  4. useHardwareProfileBindingState.ts is a new file (not a modification) On main, this file existed and PR On notebook start/stop, remove hwp annotations from notebook when hwp is deleted #5392 only modified it. On stable-2.x, the file doesn't exist at all, so the entire file had to be added.

  5. DeploymentHardwareProfileCell.tsx and HardwareProfileTableColumn.tsx are dropped These files exist on main but not on stable-2.x. PR On notebook start/stop, remove hwp annotations from notebook when hwp is deleted #5392 modified them to pass bindingState as a prop. Since the files don't exist on stable-2.x, those changes are not applicable.

  6. NotebookTableRow.tsx keeps stable-2.x UI components On main, the hardware profile column uses HardwareProfileTableColumn. On stable-2.x, it uses NotebookTableRowHardwareProfile. I kept the stable-2.x UI but added the binding state + extra patches for start/stop (the actual bug fix).

  7. utils.ts omits resourceTypeOf PR On notebook start/stop, remove hwp annotations from notebook when hwp is deleted #5392 added both getDeletedHardwareProfilePatches and resourceTypeOf. The latter was only used by HardwareProfileTableColumn which doesn't exist on stable-2.x, so it was omitted.

  8. Cypress test removes findHardwareProfileColumn assertion This test helper method doesn't exist on stable-2.x's page object, and HardwareProfileModel import was missing from the auto-merge.

The core fix is identical: extraPatches on startNotebook/stopNotebook, the REMOVE_HARDWARE_PROFILE_ANNOTATIONS_PATCH constant, getDeletedHardwareProfilePatches utility, useHardwareProfileBindingState hook with the DELETED early-return, and the call sites passing those patches. The differences are all adaptations to dependencies and UI components that differ between the two branches.

@coderabbitai

coderabbitai Bot commented Mar 27, 2026

Copy link
Copy Markdown
Contributor

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: c1a418e8-56c2-4dd3-979a-6dc4113b1382

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

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

Comment thread frontend/src/concepts/hardwareProfiles/useHardwareProfileBindingState.ts Outdated
@srtanish1992

Copy link
Copy Markdown
Contributor Author

/retest

@srtanish1992

Copy link
Copy Markdown
Contributor Author

@DaoDaoNoCode
I have tested locally and the bug is no longer present. The only cosmetic difference with main branch is that once the HW profile is deleted, on main we display Deleted whereas in these changes we continue displaying Custom, I think that's fine since the core bug is fixed.

wb_bug.mp4

import useHardwareProfile from '#~/pages/hardwareProfiles/useHardwareProfile';
import { HardwareProfileBindingState } from './const';

export const useHardwareProfileBindingState = (

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this was a new feature introduced to 3.0 GA, I'm not sure if we can add this to 2.5.x like this

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good point @nananosirova
I have simplified the hook to only fix the bug in d743e70

@codecov

codecov Bot commented Mar 27, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 76.47059% with 12 lines in your changes missing coverage. Please review.
✅ Project coverage is 67.68%. Comparing base (6792a5d) to head (a7faca0).
⚠️ Report is 24 commits behind head on stable-2.x.

Files with missing lines Patch % Lines
...hardwareProfiles/useHardwareProfileBindingState.ts 60.00% 12 Missing ⚠️
Additional details and impacted files

Impacted file tree graph

@@              Coverage Diff               @@
##           stable-2.x    #6947      +/-   ##
==============================================
- Coverage       67.85%   67.68%   -0.18%     
==============================================
  Files            2235     2238       +3     
  Lines           50753    50876     +123     
  Branches        14208    14267      +59     
==============================================
- Hits            34439    34433       -6     
- Misses          16314    16443     +129     
Files with missing lines Coverage Δ
frontend/src/api/k8s/notebooks.ts 91.51% <100.00%> (+0.15%) ⬆️
frontend/src/concepts/hardwareProfiles/const.ts 100.00% <100.00%> (ø)
frontend/src/concepts/hardwareProfiles/types.ts 100.00% <ø> (ø)
frontend/src/concepts/hardwareProfiles/utils.ts 92.47% <100.00%> (+0.51%) ⬆️
...ects/screens/detail/notebooks/NotebookTableRow.tsx 94.02% <100.00%> (+0.18%) ⬆️
...reens/projects/ProjectTableRowNotebookTableRow.tsx 77.14% <100.00%> (+1.38%) ⬆️
...hardwareProfiles/useHardwareProfileBindingState.ts 60.00% <60.00%> (ø)

... and 47 files with indirect coverage changes


Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6792a5d...a7faca0. Read the comment docs.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

nananosirova and others added 3 commits March 29, 2026 23:29
… is deleted (opendatahub-io#5392)

* On notebook start/stop, remove hwp annotations from notebook when hwp is deleted

* Ensure deleted label persists on notebook stop/start

* Avoid duplicate hook call in HardwareProfileTableColumn

* Fix tests
Replace useHardwareProfileBindingState (3.0 feature code) with a
minimal useDeletedHardwareProfilePatches hook that only detects
404 on hardware profile fetch and returns removal patches.

Made-with: Cursor

@DaoDaoNoCode DaoDaoNoCode left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PR Review -- RHOAIENG-50913: A workbench cannot be stopped if its hardware profile doesn't exist

Summary

This PR is a backport of #5392 from main to stable-2.x. It fixes a bug where workbenches could not be stopped or started if their associated hardware profile had been deleted. The fix adds an extraPatches parameter to startNotebook and stopNotebook to strip stale hardware profile annotations when the referenced hardware profile returns a 404. The approach is correct and the adaptation to the stable-2.x codebase is well done.

Jira AC Coverage

  • Workbench can be stopped when hardware profile is deleted -- implemented via useDeletedHardwareProfilePatches hook + extraPatches on stopNotebook
  • Workbench can be started when hardware profile is deleted -- implemented via extraPatches on startNotebook
  • Hardware profile annotations are cleaned up on stop/start -- REMOVE_HARDWARE_PROFILE_ANNOTATIONS_PATCH removes name and namespace annotations

Test Coverage

  • Unit tests: Not present for useDeletedHardwareProfilePatches -- consistent with the original PR #5392 on main which also lacks unit tests for this hook. See inline suggestion.
  • Cypress mock tests: Present -- two comprehensive tests covering stop and start scenarios with deleted hardware profiles, including request payload validation.
  • data-testid attributes: N/A -- no new UI elements added.

CI / Local Test Results

Check Result
Lint PASS
Type-check (frontend) PASS (pre-existing llama-stack-client errors only)
Type-check (backend) FAIL (pre-existing, unrelated to this PR)
Cypress mock (projects/tabs) FAIL (infra: turbo: not found)
Cypress mock (storageClasses) FAIL (infra: turbo: not found)

All CI failures are infrastructure issues (turbo: not found in the runner environment), not caused by this PR's code changes.

Overall

APPROVED

The core bug fix is correct and matches the original PR on main. The backport adaptations are well-reasoned (keeping tolerationChanges, simplified hook without binding state UI, dropping files that don't exist on stable-2.x). Inline suggestions are non-blocking improvements.

if (hardwareProfileName && loaded && loadError && getGenericErrorCode(loadError) === 404) {
return REMOVE_HARDWARE_PROFILE_ANNOTATIONS_PATCH;
}
return [];

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[SUGGESTION]

This returns a new empty array [] on every render when the hardware profile is not deleted (the common path). Since deletedHardwareProfilePatches is used in useCallback dependency arrays in both NotebookTableRow and ProjectTableRowNotebookTableRow, this causes onStart and handleStop callbacks to be recreated on every render.

Consider using a module-level constant for the empty array to ensure reference stability:

Suggested change
return [];
const EMPTY_PATCHES: Patch[] = [];
// ... (at the top of the file, after imports)
// then in the hook:
return EMPTY_PATCHES;

REMOVE_HARDWARE_PROFILE_ANNOTATIONS_PATCH is already a module-level constant so the deleted-profile path is already stable.

return [];
};

export default useDeletedHardwareProfilePatches;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[SUGGESTION]

No unit test exists for this hook. While the original PR #5392 on main also lacks one, this would be a good candidate for a testHook unit test since the logic is straightforward to test in isolation (mock useHardwareProfile to return loaded+404 error, verify patches are returned; mock it to return loaded+no error, verify empty array).

Not blocking since the Cypress mock tests cover the end-to-end behavior.

@openshift-ci

openshift-ci Bot commented Mar 30, 2026

Copy link
Copy Markdown
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: DaoDaoNoCode

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:

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

@openshift-merge-bot
openshift-merge-bot Bot merged commit 117bbcd into opendatahub-io:stable-2.x Mar 30, 2026
171 of 182 checks passed
@DaoDaoNoCode

Copy link
Copy Markdown
Member

CI Failure Analysis -- Supplemental Note

Failing Jobs

Job Conclusion Root Cause
Cypress-Mock-Tests (projects/tabs) FAIL GitHub Actions cache miss
Cypress-Mock-Tests (storageClasses) FAIL GitHub Actions cache miss

Root Cause: GitHub Actions Cache Eviction

Both failures are caused by GitHub Actions cache misses, not by any test or code issue. The evidence:

  1. Passing jobs ran at 03:35-03:38 UTC on March 30 and got cache hits:

    • Cache restored from key: Linux-20.x-all-modules-771b5d...
    • Cache restored from key: Linux-20.x-cypress-build-8d34a...
  2. Failing jobs ran ~15 hours later at 18:22-18:23 UTC, by which time the cache had been evicted:

    • Cache not found for input keys: Linux-20.x-all-modules-771b5d...
    • Cache not found for input keys: Linux-20.x-cypress-build-8d34a...
  3. Without node_modules, turbo is not found, and the jobs exit immediately with code 127 before any test code is executed.

Impact on This PR

The projects/tabs test group contains the new workbench tests added by this PR (workbench.cy.ts). Because this job failed at infrastructure level, the new Cypress tests were never actually executed in CI. A re-run of the CI workflow should resolve this, as it will create fresh caches.

The storageClasses failure is unrelated to this PR -- no files in that test group were modified.

Verification

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants