CONSOLE-5055: AsyncComponent type improvements by logonoff · Pull Request #16002 · openshift/console

logonoff · 2026-02-05T19:57:05Z

Updated AsyncComponent to be a functional component that uses React.lazy
Retry duration is now capped to 30s instead of exponentially increasing (previously we would backoff for over a month)
- To be honest we probably don't need to have any retry behaivour here. But I kept it incase just in case
Components consuming AsyncComponent now have proper type checking based on the props of the loader

Summary by CodeRabbit

Bug Fixes
- Improved reliability of component loading with automatic retry and exponential backoff for better error recovery.
New Features
- Added localization support for edit mode in YAML creation workflows.
Tests
- Enhanced test coverage for async component error handling and retry behavior with backoff timing verification.

openshift-ci-robot · 2026-02-05T19:57:09Z

@logonoff: This pull request references CONSOLE-5055 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Updated AsyncComponent to be a functional component that uses React.lazy

Retry duration is now capped to 30s instead of exponentially increasing (previously we would backoff for over a month)

Component consuming AsyncComponent now have proper type checking based on the props of the loader

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 · 2026-02-05T19:58:17Z

@logonoff: This pull request references CONSOLE-5055 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Updated AsyncComponent to be a functional component that uses React.lazy

Retry duration is now capped to 30s instead of exponentially increasing (previously we would backoff for over a month)

To be honest we probably don't need to have any retry behaivour here. But I kept it incase just in case

Component consuming AsyncComponent now have proper type checking based on the props of the loader

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 · 2026-02-05T19:58:23Z

@logonoff: This pull request references CONSOLE-5055 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Updated AsyncComponent to be a functional component that uses React.lazy

Retry duration is now capped to 30s instead of exponentially increasing (previously we would backoff for over a month)

To be honest we probably don't need to have any retry behaivour here. But I kept it incase just in case

Components consuming AsyncComponent now have proper type checking based on the props of the loader

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 · 2026-02-05T20:00:29Z

@logonoff: This pull request references CONSOLE-5055 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Updated AsyncComponent to be a functional component that uses React.lazy

Retry duration is now capped to 30s instead of exponentially increasing (previously we would backoff for over a month)

To be honest we probably don't need to have any retry behaivour here. But I kept it incase just in case

Components consuming AsyncComponent now have proper type checking based on the props of the loader

Summary by CodeRabbit

Bug Fixes

Improved reliability of component loading with automatic retry and exponential backoff for better error recovery.

New Features

Added localization support for edit mode in YAML creation workflows.

Tests

Enhanced test coverage for async component error handling and retry behavior with backoff timing verification.

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.

logonoff · 2026-02-05T20:02:53Z

/label px-approved
/label docs-approved

coderabbitai · 2026-02-05T20:03:35Z

📝 Walkthrough

Walkthrough

This pull request refactors the AsyncComponent lazy-loading system from class-based to functional component using hooks and Suspense, introducing exponential backoff retry logic with a configurable retry cap. Type signatures across lazy loaders are updated to expect ComponentType instead of raw props, with corresponding type adjustments in dependent components. Error boundaries are selectively removed from certain lazy-loaded resources. Props are refined to make create and clearFileUpload optional in EditYAMLProps. Test coverage expands for async error and retry scenarios. Data-test attributes are added to buttons for improved testing visibility. Minor type imports are consolidated and React type references are simplified throughout.

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title directly reflects the main change: converting AsyncComponent to use better type checking and functional approach with retry improvements.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

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

✨ Finishing touches

📝 Generate docstrings

🧪 Generate unit tests (beta)

Create PR with unit tests
Post copyable unit tests in a comment

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

coderabbitai

Actionable comments posted: 0

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

frontend/public/components/import-yaml.tsx (1)
16-25: ⚠️ Potential issue | 🟡 Minor

Fix type safety: initialResource={undefined} violates the required prop definition.

ResourceYAMLEditorProps defines initialResource: K8sResourceKind as required (not optional). Passing undefined conflicts with this contract. In create-yaml.tsx, the pattern correctly uses an empty object {} instead:
const initialResource = useMemo(() => {
  if (!kindObj) {
    return {};  // Always pass an object
  }
  // ...
}, []);
Either mark initialResource as optional in ResourceYAMLEditorProps if undefined should be supported, or pass {} here to align with the type definition and existing usage patterns.

🧹 Nitpick comments (3)

frontend/packages/console-shared/src/components/formik-fields/field-types.ts (1)

166-173: Minor inconsistency between RadioButtonFieldProps and RadioGroupFieldProps value types.

RadioButtonFieldProps.value accepts string | number (line 167), while RadioGroupOption.value is constrained to string only (line 185). If a RadioButtonField is used standalone with a numeric value but the same field is later wrapped in a RadioGroupField, the types won't align.

Consider whether both should consistently use string or string | number. If numeric values are genuinely needed for radio buttons, RadioGroupOption.value should also support number.

frontend/public/components/utils/async.tsx (1)

18-22: sameLoader comparison is fragile — document limitations and consider alternatives.

Comparing functions via name and toString() can produce false positives (different inline functions with identical bodies) or false negatives (minified code where function bodies differ). The current approach handles inline loaders better than referential equality alone, but:

Arrow functions typically have empty name properties

Minifiers may alter function bodies unpredictably

The comment acknowledges this ("not the best solution"), but consider adding a more robust equality check or documenting that consumers should define loaders outside render cycles when possible.
frontend/public/components/utils/__tests__/async.spec.tsx (1)
98-109: Minor: Missing await after advanceTimersByTime may cause timing issues.

For consistency with other tests in this file, consider wrapping the timer advancement in act or awaiting promise resolution:
await act(async () => {
  jest.advanceTimersByTime(1000);
});
This ensures all pending promise resolutions are flushed before the assertion on line 107.
♻️ Suggested improvement
   await waitFor(() => expect(loader).toHaveBeenCalledTimes(1));

-  jest.advanceTimersByTime(1000);
+  await act(async () => {
+    jest.advanceTimersByTime(1000);
+  });

   expect(loader).toHaveBeenCalledTimes(1);

TheRealJon · 2026-02-10T19:23:30Z

/woof

openshift-ci · 2026-02-10T19:23:34Z

@TheRealJon:

Details

In response to this:

/woof

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.

TheRealJon

Just a couple of questions about the kind props being removed.

TheRealJon · 2026-02-10T19:46:51Z

frontend/public/components/app-contents.tsx

        path="/k8s/ns/:ns/secrets/~new/:type"
        element={
          <AsyncComponent
-            kind="Secret"


Is this safe?

m.CreateSecret takes no props

export const CreateSecret = () => { const params = useParams(); const formType = params.type as SecretFormType; return ( <SecretFormWrapper fixed={{ metadata: { namespace: params.ns } }} formType={formType} isCreate={true} /> ); };

TheRealJon · 2026-02-10T19:49:26Z

frontend/public/components/create-yaml.tsx

      loader={() => import('./droppable-edit-yaml').then((c) => c.DroppableEditYAML)}
      initialResource={initialResource}
      create={isCreate}
-      kind={kindObj.kind}


Is this safe?

kind is not a prop in either DroppableEditYAML nor EditYAML. props.kind is not accessed in either component either

logonoff · 2026-02-10T19:57:21Z

frontend/packages/console-shared/src/components/formik-fields/CodeEditorField.tsx

-            forwardRef={editorRef}
+            ref={editorRef}


CodeEditor never accepted forwardRef, the way to pass a ref to a component is via the ref prop

logonoff · 2026-02-10T19:58:02Z

frontend/packages/operator-lifecycle-manager/src/components/operand/create-operand.tsx

-          <ErrorBoundaryPage>
-            <AsyncComponent
-              loader={createResourceExtension.properties.component}
-              namespace={params.ns}
-            />
-          </ErrorBoundaryPage>
+          <AsyncComponent
+            loader={createResourceExtension.properties.component}
+            namespace={params.ns}
+          />


AsyncComponent now wraps an ErrorBoundary

logonoff · 2026-02-10T19:58:50Z

frontend/public/components/app-contents.tsx

        path="/k8s/ns/:ns/secrets/~new/:type"
        element={
          <AsyncComponent
-            kind="Secret"


m.CreateSecret takes no props

export const CreateSecret = () => { const params = useParams(); const formType = params.type as SecretFormType; return ( <SecretFormWrapper fixed={{ metadata: { namespace: params.ns } }} formType={formType} isCreate={true} /> ); };

logonoff · 2026-02-10T19:59:11Z

frontend/public/components/app-contents.tsx

        path="/k8s/ns/:ns/configmaps/~new/form"
        element={
          <AsyncComponent
-            kind="ConfigMap"


ConfigMapPage accepts no props

export const ConfigMapPage: FC = () => { const { t } = useTranslation(); const { ns: namespace, name } = useParams(); const isCreateFlow: boolean = !name; const [watchedConf

logonoff · 2026-02-10T19:59:27Z

frontend/public/components/app-contents.tsx

            loader={() =>
              import('./RBAC' /* webpackChunkName: "rbac" */).then((m) => m.CreateRoleBinding)
            }
-            kind="RoleBinding"


CreateRoleBinding accepts no props

export const CreateRoleBinding: FC = () => { const params = useParams(); const location = useLocation(); const searchParams = new URLSearchParams(location.search); const roleKind = searchParams.get('rolekind'); const roleName = searchParams.get('rolename'); const subjectName = searchParams.get('subjectName'

logonoff · 2026-02-10T19:59:43Z

frontend/public/components/app-contents.tsx

        path="/k8s/ns/:ns/persistentvolumeclaims/~new/form"
        element={
          <AsyncComponent
-            kind="PersistentVolumeClaim"


accepts no props

export const CreatePVC = () => { const params = useParams(); const namespace = params.ns || 'default'; return <CreatePVC

logonoff · 2026-02-10T19:59:58Z

frontend/public/components/app-contents.tsx

        path="/k8s/ns/:ns/:resourceRef/form"
        element={
          <AsyncComponent
-            kind="PodDisruptionBudgets"


accepts no props

export const PDBFormPage: FC = () => { const { t } = useTranslation(); const params = us

logonoff · 2026-02-10T20:01:15Z

frontend/public/components/create-yaml.tsx

      loader={() => import('./droppable-edit-yaml').then((c) => c.DroppableEditYAML)}
      initialResource={initialResource}
      create={isCreate}
-      kind={kindObj.kind}


kind is not a prop in either DroppableEditYAML nor EditYAML. props.kind is not accessed in either component either

TheRealJon

/lgtm

openshift-ci · 2026-02-10T21:14:34Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: logonoff, TheRealJon

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~~ [TheRealJon,logonoff]

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

logonoff · 2026-02-11T02:19:45Z

/assign @yapei

yapei · 2026-02-12T07:17:29Z

performed some regression testing on following

Deployment & Pod Environment handling, Add/Remove/Update/Reorder environment variables
Import YAML page, drag and drop files
Enable console-demo-plugin and check Sample Error Boundary Page
Resource creation form, including workloads creation form and operand creation form
Pod debug terminal
Secret, ConfigMap, RoleBinding, ClusterRoleBinding,PDB and PVC creation form
Attach Storage form

No obvious regression issues found
/verified by @yapei and CI

openshift-ci-robot · 2026-02-12T07:17:42Z

@yapei: This PR has been marked as verified by @yapei and CI.

Details

In response to this:

performed some regression testing on following

Deployment & Pod Environment handling, Add/Remove/Update/Reorder environment variables

Import YAML page, drag and drop files

Enable console-demo-plugin and check Sample Error Boundary Page

Resource creation form, including workloads creation form and operand creation form

Pod debug terminal

Secret, ConfigMap, RoleBinding, ClusterRoleBinding,PDB and PVC creation form

Attach Storage form

No obvious regression issues found
/verified by @yapei and CI

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 · 2026-02-13T05:25:32Z

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

openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Feb 5, 2026

openshift-ci bot requested review from cajieh and rawagner February 5, 2026 19:57

openshift-ci bot added px-approved Signifies that Product Support has signed off on this PR docs-approved Signifies that Docs has signed off on this PR labels Feb 5, 2026

coderabbitai bot reviewed Feb 5, 2026

View reviewed changes

logonoff force-pushed the CONSOLE-5055-async branch 4 times, most recently from be35005 to 9cf3f71 Compare February 6, 2026 17:32

logonoff added 2 commits February 10, 2026 14:40

CONSOLE-5015: Address nit

01e4083

CONSOLE-5055: AsyncComponent type improvements

6f03cdd

logonoff force-pushed the CONSOLE-5055-async branch from 9cf3f71 to 6f03cdd Compare February 10, 2026 19:40

TheRealJon reviewed Feb 10, 2026

View reviewed changes

logonoff commented Feb 10, 2026

View reviewed changes

TheRealJon approved these changes Feb 10, 2026

View reviewed changes

openshift-ci bot assigned TheRealJon Feb 10, 2026

openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Feb 10, 2026

openshift-ci bot assigned yapei Feb 11, 2026

openshift-ci-robot added the verified Signifies that the PR passed pre-merge verification criteria label Feb 12, 2026

openshift-merge-bot bot merged commit 51671f2 into openshift:main Feb 13, 2026
8 checks passed

logonoff deleted the CONSOLE-5055-async branch February 13, 2026 06:48

This was referenced Feb 24, 2026

OCPBUGS-65728: fix dynamic plugin horizontal nav tabs failing with loader error #16055

Open

[release-4.21] OCPBUGS-77246: AsyncComponent type improvements #16058

Open

Comments

Conversation

logonoff commented Feb 5, 2026 • edited by coderabbitai bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary by CodeRabbit

Uh oh!

openshift-ci-robot commented Feb 5, 2026 • edited by openshift-ci bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openshift-ci-robot commented Feb 5, 2026 • edited by openshift-ci bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openshift-ci-robot commented Feb 5, 2026 • edited by openshift-ci bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openshift-ci-robot commented Feb 5, 2026 • edited by openshift-ci bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary by CodeRabbit

Uh oh!

logonoff commented Feb 5, 2026

Uh oh!

coderabbitai bot commented Feb 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Walkthrough

Uh oh!

coderabbitai bot left a comment

Choose a reason for hiding this comment

Uh oh!

TheRealJon commented Feb 10, 2026

Uh oh!

openshift-ci bot commented Feb 10, 2026

Uh oh!

TheRealJon left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TheRealJon left a comment

Choose a reason for hiding this comment

Uh oh!

openshift-ci bot commented Feb 10, 2026

Uh oh!

logonoff commented Feb 11, 2026

Uh oh!

yapei commented Feb 12, 2026

Uh oh!

openshift-ci-robot commented Feb 12, 2026

Uh oh!

openshift-ci bot commented Feb 13, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

logonoff commented Feb 5, 2026 •

edited by coderabbitai bot

Loading

openshift-ci-robot commented Feb 5, 2026 •

edited by openshift-ci bot

Loading

openshift-ci-robot commented Feb 5, 2026 •

edited by openshift-ci bot

Loading

openshift-ci-robot commented Feb 5, 2026 •

edited by openshift-ci bot

Loading

openshift-ci-robot commented Feb 5, 2026 •

edited by openshift-ci bot

Loading

coderabbitai bot commented Feb 5, 2026 •

edited

Loading