Commits on Feb 27, 2026 bug(settings): Entering invalid ARK breaks reset flow

[dschom]

Because

• When a user provides an invalid account recovery key, the flow would break.
• At this point, the password forgot token has been exchanged and was no longer valid

This pull request

• Adds functional tests to represent failure states when entering invalid ARK
• Prevents the password forgot token from being destroy when exchanged for an account recovery key

Issue that this pull request solves

Closes: FXA-13162

Checklist

Put an x in the boxes that apply

• My commit is GPG signed.
• If applicable, I have modified or added tests which pass locally.
• I have added necessary documentation (if appropriate).
• I have verified that my changes render correctly in RTL (if appropriate).

Screenshots (Optional)

Please attach the screenshots of the changes made in case of change in user interface.

Other information (Optional)

Note this a much cleaner approach than this other draft. The question is whether or not destroying the password forgot token is mandatory. If so maybe that other much more involved approach is necessary...

It looks like that logic was introduced here... and I see no mention for why the change was made. The commit seems more like general refactor / clean up. It's worth noting that passwordForgotTokens are being pruned by the token pruner, so imo this approach is fine...

[LZoog]

I checked out your other PR as well, and after poking around I agree this one is the better approach as it is much simpler and in checking out our code and docs, I don't immediately see why the token has to be single use.

Couple notes:

• On top of the pruning and TTL, the token gets deleted in resetAccount_19 which runs for ARK flow and non-ARK flow, with DELETE FROM passwordForgotTokens WHERE uid = uidArg;
• Does this warrant lowering the TTL? It seems reasonable to me right now (PASSWORD_FORGOT_TOKEN_TTL) in stage/prod, but I could see cutting it a little shorter

We might want Vijay's take too in case he sees something we don't. I didn't test this locally yet but I'm happy to test and r+.

[LZoog]

I think this comment was a copy/paste from the other PR and is no longer correct here.

[LZoog]

Is it worth having a comment somewhere that the only difference between this migration and the previous one is we no longer delete the token?

[LZoog]

Tested locally and verified it is working 👍

[vbudhram]

@dschom Thanks for the simplier approach. Also worth noting that when a user actual completes the reset, those tokens are removed

fxa/packages/db-migrations/databases/fxa/patches/patch-159-160.sql

Line 36 in e3da348

DELETE FROM passwordForgotTokens WHERE uid = uidArg;