Testing recovery contact changes as a state transition

Goal

Check which recovery destinations become effective during a contact-change workflow. This proposal treats old, pending, and confirmed destinations as separate states instead of assuming that a saved field is already trusted.

Prerequisites

Use a disposable account system, synthetic contact addresses, and a local delivery sink. Define when the new destination may recover the account and when the old destination must stop working.

Steps

1. Establish the original verified contact and perform a harmless recovery-flow control in the lab. Record only synthetic delivery labels and the resulting account state.

2. Begin a contact change without completing its confirmation step. Trigger recovery through the normal test interface and compare delivery and eligibility with the declared pending-state policy.

3. Complete confirmation and repeat recovery. Inspect both old and new destinations, distinguishing a notification of change from a message that actually grants recovery authority.

4. Cancel or expire a separate pending change using the fixture’s supported administrative controls. Confirm that the abandoned destination never becomes effective through a later unrelated profile update.

5. Add state-transition assertions around the contact-change implementation. Rerun ordinary recovery and contact updates so that rejecting all recovery requests cannot count as a successful repair.

Expected result

The result should be a state table showing which synthetic destination has recovery authority at each transition and which messages merely communicate an event.

Limits and test basis

No email-provider behavior or recovery-token cryptography is evaluated here. This method only proposes tests of the application’s chosen contact lifecycle and requires a controlled delivery environment. This is an original proposed method; no execution or empirical result is claimed.