fix(dashboard): stop member access catalog refetch loop - #1024
Merged
Merged
Conversation
5 tasks done
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Keep the member access editor's catalog callback stable so loading labels does not restart the resource fetch.
Motivation
Opening a member's permissions can leave the picker in a fetch/render loop instead of loading usable settings.
ResourcePickerhas a fetch effect that depends ononCatalogLoaded; the editor recreated that callback after every label update. This addresses #1014.Related issue
Closes #1014.
Changes
apps/dashboard: memoizeonCatalogLoadedinAccessEditorModal.Verification
Tested from upstream
0ca13fewith this branch ate7b9179on Windows, Bun 1.3.10, Node 24.On the default Windows checkout, one existing dashboard test compares a literal LF sequence with
useDeploymentConfig.ts, which Git checked out as CRLF (2,407/2,408 pass). The repository-levelbun run teststill fails in@repo/adapters: 4,464 pass, 194 fail, 72 skip; one recorded error isspawn shENOENT on Windows.bun install --frozen-lockfilealso ended with an@repo/emailpostinstall EPERM for@zero/server, although the dashboard dependencies and checks above ran. I did not run the full repo-writingbun formatcommand; the touched files pass Prettier's check.Screenshots
No full signed-in team workspace was launched for screenshots. The regression test mounts the actual editor and verifies a visible catalog label plus request count.
Checklist
bun run test, relevant lint, andbun formatall pass locally (repository-level Windows blockers detailed above; relevant lint and scoped format check pass)