Skip to content

OCPBUGS-72598 | [OVE] Custom manifests are broken in local Assisted UI #3374

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
asmasarw wants to merge 1 commit into
base: master
Choose a base branch
from
Open

OCPBUGS-72598 | [OVE] Custom manifests are broken in local Assisted UI #3374

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 6 additions & 2 deletions libs/ui-lib/lib/ocm/components/clusterWizard/ClusterWizardContextProvider.tsx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -160,10 +160,14 @@ const ClusterWizardContextProvider = ({
isSingleClusterFeatureEnabled,
);

// Only move step if there is still none, or the user is at a forbidden step
// Only move step if there is still none, or the user is at a forbidden step.
// Never force the user off the custom-manifests step when they are actively filling it
// (e.g. after pasting content triggers auto-save and uiSettings can update).
if (
!currentStepId ||
(customManifestsStepNeedsToBeFilled && isStepAfter(currentStepId, requiredStepId))
(currentStepId !== 'custom-manifests' &&
customManifestsStepNeedsToBeFilled &&
isStepAfter(currentStepId, requiredStepId))
Comment on lines 166 to +170
Copy link
Member

@rawagner rawagner Feb 2, 2026 •
edited
Loading

Choose a reason for hiding this comment

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

I dont understand the fix. This useEffect is triggered when user opens the wizard and settings are loaded/or settings are changed. How can this have some effect on copying content into custom manifests field ? the settings should be loaded already, right ?

That leaves out that uiSettings changed and maybe we dont calculate customManifestsStepNeedsToBeFilled properly ?

Can you explain what is the root cause that triggers the original condition which changes the current step?

Copy link
Contributor Author

@asmasarw asmasarw Feb 2, 2026

Choose a reason for hiding this comment

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

@rawagner - when user paste content it changes the uisettings indirectly - see explanations below.

Why does pasting in Custom Manifests reset the wizard to Cluster Details?

1. How does pasting cause the effect to run?

Pasting does not change "wizard settings" directly. It does trigger a chain that updates
uiSettings:

  1. User pastes in the CodeField → setValue(text, true) (CodeField.tsx).
  2. Formik values change for the manifest YAML field.
  3. CustomManifestsForm uses useFormikAutoSave() (debounced ~1s). When values change, it
    calls submitForm().
  4. handleSubmit in CustomManifestsForm.tsx runs. For a new manifest (not yet saved), it:
    • Calls ClustersAPI.createCustomManifest(...)
    • Then:
      if (!uiSettings?.customManifestsAdded) { await updateUISettings({ customManifestsAdded: true }); }
  5. So as a direct result of the paste → auto-save flow, we call
    updateUISettings({ customManifestsAdded: true })    .
  6. That updates state in useUISettings → uiSettings gets a new reference.
  7. ClusterWizardContextProvider uses useUISettings() and has a useEffect that depends on
    [uiSettings, UISettingsLoading, UISettingsError].
  8. So when uiSettings changes (after the paste → auto-save → updateUISettings chain), the effect
    runs    .

So: settings are not “already loaded and never change.” Pasting triggers auto-save, which
explicitly updates uiSettings, and that is what triggers the effect.

2. What is the condition that changes the current step?

In ClusterWizardContextProvider.tsx, the effect does:

const customManifestsStepNeedsToBeFilled = !!(
  uiSettings?.addCustomManifests && !uiSettings?.customManifestsAdded
);

const requiredStepId = getClusterWizardFirstStep(
  locationState,
  staticIpInfo,
  cluster?.status,
  cluster?.hosts,
  customManifestsStepNeedsToBeFilled,
);

if (
  !currentStepId ||
  (customManifestsStepNeedsToBeFilled && isStepAfter(currentStepId, requiredStepId))
) {
  setCurrentStepId(requiredStepId);
}

So the step is changed when:

  • !currentStepId (initial step), or
  • customManifestsStepNeedsToBeFilled && isStepAfter(currentStepId, requiredStepId) (user is
    “ahead” of the required step and we force them back to requiredStepId).

Copy link
Member

@rawagner rawagner Feb 2, 2026

Choose a reason for hiding this comment

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

The AI nicely described the few lines of code we have here.. but didnt really answer anything :)

Lets take a closer look at the original condition

if (
  !currentStepId ||
  (customManifestsStepNeedsToBeFilled && isStepAfter(currentStepId, requiredStepId))
) {
  setCurrentStepId(requiredStepId);
}

the step changes if:
a) currentStepId is undefined -> in our case I believe it is it is
b) customManifestsStepNeedsToBeFilled is truthy and isStepAfter is truthy

customManifestsStepNeedsToBeFilled is

const customManifestsStepNeedsToBeFilled = !!(
  uiSettings?.addCustomManifests && !uiSettings?.customManifestsAdded
);

it seems the bug is here - how can customManifestsStepNeedsToBeFilled be true, if we just added the custom manifest ?

) {
setCurrentStepId(requiredStepId);
}
Expand Down
Loading