OCPBUGS-111081: Fix Installed Operators page error for namespace-scoped RBAC users

[platex-rehor-bot]

Analysis / Root cause:

When the Firehose component was replaced by React hooks in MultiListPage (as part of CONSOLE-5026), the loadError computation in list-page.tsx lost the check that excluded resources declared with optional: true from contributing to the page's fatal error.

In 4.21, firehose.jsx explicitly filtered optional resources out before computing loadError:

const required = _.filter(resources, (r) => !r.optional);
const loadError = worstError(_.map(required, 'loadError').filter(Boolean));

In 4.22, the replacement code in list-page.tsx uses Object.values(watchedResources) which discards the resource key, and has no reference to the optional flag — so any resource error, including from optional resources, becomes a fatal page error.

The Installed Operators page declares CatalogSource as optional: true (cluster-scoped lookup used only for catalog-health badges). For users whose RBAC is delivered entirely via namespace-scoped RoleBindings (no ClusterRoleBinding), this cluster-scoped fetch returns 403, which now becomes a fatal page error instead of being silently tolerated.

Solution description:

Modified the loadError computation in MultiListPage to cross-reference each watched resource's key against the watchResources input config (which still carries the optional flag). Resources declared optional: true are excluded from the fatal error calculation, restoring the 4.21 behavior.

The fix is in the shared MultiListPage infrastructure (list-page.tsx), not in any Operators-specific code, so it correctly handles all current and future uses of optional: true across the console.

Screenshots / screen recording:

Test setup:

1. On an OCP 4.22+ cluster, create a namespace and install any catalog Operator into it.
2. Create a test user with namespace-scoped RoleBindings only (no ClusterRoleBinding).
3. Log in as the test user and navigate to Operators → Installed Operators for that namespace.

Test cases:

• Verify the Installed Operators page renders correctly for users with namespace-scoped RBAC only (no cluster-scope CatalogSource access).
• Verify the page still shows errors for non-optional resource failures (e.g., if the ClusterServiceVersion fetch itself fails).
• Unit tests added to verify optional resource errors are excluded from loadError and non-optional errors are preserved.

Browser conformance:

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

Additional info:

• Jira: OCPBUGS-111081
• Regression introduced by openshift/console#16096 (Firehose → hooks migration)
• Reported via Red Hat support case 04489721 (Ford Motor Company)
• Detailed root cause analysis available in the Jira ticket comments

🤖 Generated with Claude Code

[openshift-ci-robot]

@platex-rehor-bot: This pull request references Jira Issue OCPBUGS-111081, which is invalid:

• expected the bug to target the "5.1.0" version, but no target version was set

Comment /jira refresh to re-evaluate validity if changes to the Jira bug are made, or edit the title of this pull request to link to a different bug.

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

Details

In response to this:

Analysis / Root cause:

When the Firehose component was replaced by React hooks in MultiListPage (as part of CONSOLE-5026), the loadError computation in list-page.tsx lost the check that excluded resources declared with optional: true from contributing to the page's fatal error.

In 4.21, firehose.jsx explicitly filtered optional resources out before computing loadError:

const required = _.filter(resources, (r) => !r.optional);
const loadError = worstError(_.map(required, 'loadError').filter(Boolean));

In 4.22, the replacement code in list-page.tsx uses Object.values(watchedResources) which discards the resource key, and has no reference to the optional flag — so any resource error, including from optional resources, becomes a fatal page error.

The Installed Operators page declares CatalogSource as optional: true (cluster-scoped lookup used only for catalog-health badges). For users whose RBAC is delivered entirely via namespace-scoped RoleBindings (no ClusterRoleBinding), this cluster-scoped fetch returns 403, which now becomes a fatal page error instead of being silently tolerated.

Solution description:

Modified the loadError computation in MultiListPage to cross-reference each watched resource's key against the watchResources input config (which still carries the optional flag). Resources declared optional: true are excluded from the fatal error calculation, restoring the 4.21 behavior.

The fix is in the shared MultiListPage infrastructure (list-page.tsx), not in any Operators-specific code, so it correctly handles all current and future uses of optional: true across the console.

Screenshots / screen recording:

Test setup:

1. On an OCP 4.22+ cluster, create a namespace and install any catalog Operator into it.
2. Create a test user with namespace-scoped RoleBindings only (no ClusterRoleBinding).
3. Log in as the test user and navigate to Operators → Installed Operators for that namespace.

Test cases:

• Verify the Installed Operators page renders correctly for users with namespace-scoped RBAC only (no cluster-scope CatalogSource access).
• Verify the page still shows errors for non-optional resource failures (e.g., if the ClusterServiceVersion fetch itself fails).
• Unit tests added to verify optional resource errors are excluded from loadError and non-optional errors are preserved.

Browser conformance:

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

Additional info:

• Jira: OCPBUGS-111081
• Regression introduced by openshift/console#16096 (Firehose → hooks migration)
• Reported via Red Hat support case 04489721 (Ford Motor Company)
• Detailed root cause analysis available in the Jira ticket comments

🤖 Generated with Claude Code

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-merge-bot]

Pipeline controller notification
This repo is configured to use the pipeline controller. Second-stage tests will be triggered either automatically or after lgtm label is added, depending on the repository configuration. The pipeline controller will automatically detect which contexts are required and will utilize /test Prow commands to trigger the second stage.

For optional jobs, comment /test ? to see a list of all defined jobs. To trigger manually all jobs from second stage use /pipeline required command.

This repository is configured in: LGTM mode

[coderabbitai]

Warning

Review limit reached

@platex-rehor-bot, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 15 minutes

Limit details: You’ve used all 2 included reviews currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

Wait for the limit to reset, then comment @coderabbitai review or push new commits to the PR.

An organization admin can change what happens after included review limits in Billing.

How do review limits work?

CodeRabbit enforces per-developer PR review limits within each organization.

For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

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

Review profile: CHILL

Plan: Pro Plus

Run ID: f6de5ee2-5a12-4d0b-bef0-e1ec605d609e

📥 Commits

Reviewing files that changed from the base of the PR and between 9d6a5b0 and 77805ef.

📒 Files selected for processing (2)

• frontend/public/components/factory/__tests__/list-page.spec.tsx
• frontend/public/components/factory/list-page.tsx

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[openshift-ci]

Hi @platex-rehor-bot. Thanks for your PR.

I'm waiting for a openshift member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Tip

We noticed you've done this a few times! Consider joining the org to skip this step and gain /lgtm and other bot rights. We recommend asking approvers on your previous PRs to sponsor you.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[platex-rehor-bot]

/jira refresh

[openshift-ci-robot]

@platex-rehor-bot: This pull request references Jira Issue OCPBUGS-111081, which is valid.

3 validation(s) were run on this bug

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

Details

In response to this:

/jira refresh

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.

[jhadvig]

/ok-to-test

[jhadvig]

/lgtm
/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jhadvig, platex-rehor-bot

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 [jhadvig]

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]

Scheduling tests matching the pipeline_run_if_changed or not excluded by pipeline_skip_if_only_changed parameters:
/test e2e-gcp-console
/test e2e-playwright

[jhadvig]

/retest

[jhadvig]

Hey @platex-rehor-bot 👍

ci/prow/frontend is failing with 1 ESLint error — a Prettier formatting violation in list-page.tsx:

609:25  error  Replace `⏎··········!(r.loadError·instanceof·NoModelError)·&&⏎·········` with `·!(r.loadError·instanceof·NoModelError)·&&`  prettier/prettier

The multi-line formatting in the loadError useMemo doesn't match Prettier's expected output. Running yarn eslint --fix frontend/public/components/factory/list-page.tsx (or just npx prettier --write on the file) should auto-fix it.

Also worth noting: MAX_WARNINGS is currently enforced as an exact count (342), not a ceiling. If this PR doesn't change the warning count, no update needed, but if it does you'll need to adjust MAX_WARNINGS in frontend/package.json to match.

[openshift-ci]

@platex-rehor-bot: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/e2e-gcp-console	77805ef	link	true	/test e2e-gcp-console
ci/prow/e2e-playwright	77805ef	link	false	/test e2e-playwright
ci/prow/frontend	77805ef	link	true	/test frontend

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.