fix(cluster): update cached resetPassword before navigating after admin setup - #1599
Open
Devin-Holland wants to merge 2 commits into
Open
fix(cluster): update cached resetPassword before navigating after admin setup#1599Devin-Holland wants to merge 2 commits into
Devin-Holland wants to merge 2 commits into
Conversation
…in setup The reset-password mutation PATCHes central-manager, but nothing updated the react-query cluster cache — router.invalidate() only re-runs route loaders. Navigating to ClusterHome then read the same [clusterId] query with a stale resetPassword: true (10s poll), and its guard bounced the user straight back to finish-setup. Intermittent by poll timing. Set the cached flag synchronously in onSuccess (not optimistic: the CM write is awaited inside the mutation before it succeeds).
Contributor
There was a problem hiding this comment.
Code Review
This pull request introduces a markClusterPasswordSet utility to synchronously update the cached cluster's resetPassword state to false upon successful setup completion, preventing navigation bounces caused by stale polling data. Unit tests have been added to verify this cache update behavior. The feedback suggests explicitly typing the setQueryData call with the Cluster generic to maintain strict type safety and prevent potential TypeScript compilation errors.
Coverage Report
File Coverage
|
||||||||||||||||||||||||||||||||||||||||||||
kriszyp
reviewed
Aug 5, 2026
kriszyp
left a comment
Member
There was a problem hiding this comment.
One codex suggestion
🤖 Reviewed with Codex
…d Cluster generic
cancelQueries({ exact: true }) before setQueryData prevents a 10s background
poll that arrives after setup succeeds from overwriting resetPassword: false
back to true and re-triggering the redirect loop. Adds <Cluster> generic to
setQueryData for type safety. Updates three existing tests to async/await and
adds a deferred-query test that verifies the cancellation protects the cache.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
kriszyp
approved these changes
Aug 7, 2026
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.
Human-Review-Need: 4 @ 7bd97bc
What
After creating the initial admin user, FinishSetup showed the "Login successful" toast but sometimes never left the setup page.
Why
The reset-password mutation PATCHes central-manager's
resetPasswordflag (awaited, so the server write is confirmed), but nothing updated the react-query cluster cache —router.invalidate()only re-runs route loaders. The subsequentnavigate('../')landed on ClusterHome, which routes oncluster.resetPasswordfrom the same[clusterId]query — still cachedtrueuntil the next 10s poll tick — so its guard bounced the user straight back tofinish-setup. Intermittent by poll timing, which is why it reproduced only sometimes.Change
New
markClusterPasswordSet(queryClient, clusterId)helper next to the query flipsresetPasswordoff in the cache; FinishSetup'sonSuccesscalls it before navigating. Not an optimistic update — the CM write has already succeeded by the timeonSuccessruns.Verification
tsc -bclean.!resetPasswordguard: both possible destinations (../and../sign-in) resolve to the cluster home for a now-connected user, so no new dead-end.— devain (Claude)