fix(rbac): improve edit/create role page performance

[karthikjeeyar]

Hey, I just made a Pull Request!

Improves RBAC create/edit role page performance.

Summary

• Replace upfront loading of all catalog users/groups with server-side search (searchMembers) fetching only the members assigned to a role (getMembersByRefs)
• Add debounced search (300ms) to the users/groups dropdown with first 100 entities loaded by default
• Fetch only required fields when resolving member references, with batching (2000 per request)
• Change getMembers() calls to getMembers(1, 1) for authentication checks (eg: to enable edit button in role page) instead of fetching all entities

Screenshots:

Before fix

Issues	Screenshots
Stuck in loading phase
Unresponsive browser
Edit button in role edit page disabled for a very long time.

After fix

RBAC_Page_Performance_fixed.mov

How to test

1. Add the following to your app-config.yaml under catalog.locations:

   - type: url
     target: https://github.com/karthikjeeyar/DevRepo/blob/master/load-testing/5k-org-entities.yaml
     rules:
       - allow: [User, Group]

✔️ Checklist

• A changeset describing the change and affected packages. (more info)
• Added or updated documentation
• Tests for new functionality and regression tests for bug fixes
• Screenshots attached (for UI changes)
• All your commits have a Signed-off-by line in the message. (more info)

[backstage-goalie]

Changed Packages

Package Name	Package Path	Changeset Bump	Current Version
@backstage-community/plugin-rbac	workspaces/rbac/plugins/rbac	patch	v2.1.1

[its-mitesh-kumar]

@karthikjeeyar With searchMembers hard-coded to limit=100 and a catalog of 5K+ users, if more than 100 users match a term like "dev-", the user only sees the first 100 with no way to reach the rest. For better UX, we can think of adding a "Load more" button at the bottom of the dropdown that fetches the next 100 using offset-based pagination. We can also do it as follow up PR not a blocker for this PR.
@ShiranHi @tobiastal what's your thought on this ?

[karthikjeeyar]

Yes, I noticed this limitation earlier as well. There is currently a cap of 100 items in the dropdown, and I agree there is room for improvement here, like Load more option.

I intentionally haven’t included that in this PR because it would be a new feature and I’d like to keep this change focused so that it can be safely backported. We can address the Load more experience as a follow-up PR based on UX inputs.

[its-mitesh-kumar]

Verified it with 5k+ users the crash issue has gone. PR can be merged once we addressed the above comments.

S_.2026-08-19.at.2.09.38.PM.mov

[its-mitesh-kumar]

@karthikjeeyar The memberRefs memo depends on [role], but role gets a new object reference every time roleRetry() fires from the polling interval (every 10s). Even when memberReferences content hasn't changed, memberRefs produces a new array reference, which triggers useAsyncRetry to re-call getMembersByRefs — an unnecessary network call every poll cycle.

I'd like if we can stabilize memberRefs with a deep/shallow compare so the downstream fetch only fires when the actual refs change. Since memberRefs is a flat string[], a simple element-wise comparison would work — either via a small useStableArray hook or useDeepCompareEffect from react-use (already a dependency).

[sanketpathak]

@karthikjeeyar I'm getting slight lag of 1-1.5 seconds. I've added 270 users in create role page and if I try to add or remove added users, there is delay in click. Is this expected?

Screen.Recording.2026-08-19.at.4.35.34.PM.mov

[karthikjeeyar]

@sanketpathak Good catch on the selection lag with a large number of members. The issue was already present, but hadn't been identified previously. All the auto-complete callback were re-created everytime and list item was not using a unique key.

I've now memoized the autocomplete callbacks and fixed duplicate React keys, which addresses the underlying causes of the lag. PTAL

Fix_dropdown_selection_issue.mov