---
title: "Verify a newer reset request invalidates older links when required"
description: "Request two recovery messages under a latest-link-only policy and prove the older link fails while the newer link resets the intended account."
canonical_url: "https://vostride.com/agent-library/account-recovery/new-reset-invalidates-old.md"
md_url: "https://vostride.com/agent-library/account-recovery/new-reset-invalidates-old.md"
content_kind: "recipe"
topic: "account-recovery"
---

# Verify a newer reset request invalidates older links when required

Request two recovery messages under a latest-link-only policy and prove the older link fails while the newer link resets the intended account.

## Risk

Some products allow several recovery tokens; others promise only the newest is valid. This recipe applies specifically to the latter policy and prevents an old inbox message from remaining an unexpected route into the account.

## Fixtures

- A test-owned account whose documented policy invalidates earlier reset links on reissue.
- A test inbox capable of distinguishing two messages by request marker and received sequence.
- An account recovery hook reporting active token count and credential version without secret link values.

## Steps

1. Request the first reset email and save its link through the inbox fixture; verify the application acknowledges delivery.
2. Request a second reset email and identify its distinct message; verify the hook reports the policy expected active-token state.
3. Open the first link while signed out and attempt a reset if offered; verify it is rejected as superseded or invalid.
4. Open the second link and set a unique replacement password; verify successful completion.
5. Sign in freshly using the replacement, verify the account identity, and inspect recovery state to confirm the newer request supplied the consumed token.

## Expected results

- The first reset request loses authority after the second request under the stated policy.
- The newer link remains valid and changes the intended account credential.
- The recovered account has no remaining usable reset tokens if that is the documented post-reset behavior.

## False-pass traps

- Assuming latest-link-only behavior for every application would create a false product requirement.
- Inbox sorting by subject rather than request identity can reverse the two links and invalidate the result.

## Cleanup

- Restore the fixture account and delete both run-specific recovery messages.

## Use with agent-qa

Adapt this test design to your application's acceptance criteria and configured target using the [recipe execution guide](/agent-library/software-factory/turn-a-recipe-into-an-agent-qa-test.md). External fixture setup and non-UI checks require your own supported hooks or test tooling. Validate the authored test, execute it, and inspect the completed evidence; this recipe is not a recorded test result.

## References

- [agent-qa test](/docs/agent-qa/configuration/test.md)
- [agent-qa hooks](/docs/agent-qa/guides/hooks.md)
- [agent-qa auth state](/docs/agent-qa/guides/auth-state.md)

- [Account recovery QA recipes](/agent-library/account-recovery.md)
- [Software factory QA library](/agent-library.md)
