fix(auth): never report a completed password change as failed - #105
Merged
Conversation
The remember-me write sat inside the same try as the request, so an electron-store failure (disk full, permissions, a corrupted file) returned `success: false` from a change the server had already made. The new password was live and the user was told it failed - and the dialog then asks them to retry with a current password that is no longer current, so the retry fails too. Nothing on screen ever says the change went through. The write now has its own try and logs on failure. `resetPassword` was fixed for this in #103 and `login.tsx` draws the same line ("Persisting the remember-me choice must never block the sign-in attempt"); this path was left out of that PR as out of scope. `test/change-password.test.mjs` covers the write in both directions, the rejected-change case, and the regression itself: `updateConfig` throws and the change must still report success, which fails against the old shape. Closes #104 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Code Review ✅ ApprovedIsolates the remember-me store write during OptionsAuto-apply is off → Gitar will not commit updates to this branch. Comment with these commands to change the behavior for this request:
Important Your trial ends in 4 days — upgrade now to keep code review, CI analysis, auto-apply, custom automations, and more. Was this helpful? React with 👍 / 👎 | Gitar |
alpha5611331
requested review from
anton-karlovskiy,
chmm195,
kevinkamto and
mchl7852
August 19, 2026 16:56
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.
Closes #104
The remember-me write in
changePasswordsat inside the sametryas the request:So an
electron-storefailure (disk full, permissions, a corrupted file) returnedsuccess: falsefrom a change the server had already made.Why that is worse than it sounds
The password is live at that point. The user is told the change failed, and the change-password dialog then asks them to retry with a current password that is no longer current, so the retry fails too. There is no path from that state back to a correct message: nothing on screen ever says the change went through, and the one thing the UI invites them to do cannot work.
This is the same defect fixed on the reset path in #103 (
02fdc7e), where it was sharper still because the reset code is single-use.changePasswordhas the identical shape and was left alone there only because it was outside that PR's scope.login.tsxhas drawn this line all along:// Persisting the remember-me choice must never block the sign-in attempt.The change
The store write gets its own
tryand logs on failure. The return value now depends only on what the server said, which is the only thing that reflects whether the password actually changed.Tests
New
test/change-password.test.mjs, modelled ontest/password-reset.test.mjs, registered intest/run.mjs:rememberMeis on, and not when it is offupdateConfigthrows, and the change still reports successThe last one fails against the old shape. The run log shows the throw actually happening and being caught, so it is not passing vacuously.
Verification
eslint, bothtscconfigs, andpnpm test:mainall clean locally (the set CI runs). 7 new checks.Cut from
mainat7128884, immediately after #103 merged.🤖 Generated with Claude Code