fix(backend): replace full CRD list fetch with targeted GET in /hub route (ACM-38058)#6530
fix(backend): replace full CRD list fetch with targeted GET in /hub route (ACM-38058)#6530fxiang1 wants to merge 1 commit into
Conversation
…oute (ACM-38058) The /hub route fetched the entire CRD list (~51MB) every 30 seconds per connected browser tab just to check if one specific CRD exists. This caused repeated massive memory allocations in the console-v2 pod. Replace the full list fetch with a targeted GET for the specific CRD by name, reducing the response from ~51MB to ~10KB per call. The targeted GET returns 200 when the CRD exists and 404 when it does not, which is detected by checking the response kind. Add regression test for the 404 case (CRD not found → isGlobalHub: false). Signed-off-by: fxiang1 <fxiang@redhat.com>
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: fxiang1 The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
📝 WalkthroughWalkthroughThe hub route now queries the multiclusterglobalhubs CRD directly and identifies global hub status from the returned resource kind. Tests update the CRD mock and verify that a 404 response produces ChangesHub CRD detection
Estimated code review effort: 2 (Simple) | ~10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
|
|
@fxiang1 IIRC, I think this was coded this way as a lazy way of avoiding adjusting the ServiceAccount permissions. I think we have permission to list/watch CRDs, but not get CRDs. Can you check the installer projects? Were you able to observe memory growth because of this pattern? |
|
/hold for permission updates |
|
/cc @zlayne |
|
/uncc @KevinFCormier |
@KevinFCormier Thanks! you're right we don't have get permission on CRDs, only list/watch. I don't think this is causing the memory leaks but I do see a temporary memory spike. I was testing with 10000 CRDs though but then I realized it's probably not realistic to have that many. So this change won't buy us much. |
|
These changes look good to me, assuming we are okay with adding GET permissions for CRDs. |



Root Cause Analysis
The
/hubroute handler inbackend/src/routes/hub.tsfetched the entire CRD list (~51MB) from the API server every 30 seconds per connected browser tab, just to check if a single CRD (multiclusterglobalhubs.operator.open-cluster-management.io) exists:This caused repeated massive memory allocations/deallocations in the
console-chart-console-v2pod, leading to memory spikes.Fix
Replace the full CRD list fetch with a targeted GET for the specific CRD by name:
This reduces the response from ~51MB to ~10KB per call. The targeted GET returns:
kind: CustomResourceDefinitionwhen the CRD exists →isGlobalHub: truekind: Statuswhen it does not →isGlobalHub: falseAlso removed the now-unused
ResourceListtype import.Regression Test
Added a test case that mocks a 404 response for the targeted CRD GET and verifies the handler correctly returns
isGlobalHub: false. Updated existing test mocks to match the new targeted endpoint.How to Test
npm run test:backend— all 338 tests pass (including 3 hub tests)npm run check:backend— prettier, lint, and tsc all passnpm run plugins) and verify the clusters page loads correctly/hubnetwork response — should containisGlobalHubwith correct valueIf the Multiclusterglobalhub operator is installed
isGlobalHub: trueotherwiseisGlobalHub: falseLinked Issue
Resolves ACM-38058
Summary by CodeRabbit
Bug Fixes
Tests