The reason for this was very simple: I needed to change the email address associated with our team’s Prismic repository (adlink).
Based on the logic of a user-friendly product, the process for changing an email address should be as follows:
Enter the new email address, and the system sends a verification email.
The old email address retains login access until the verification link is clicked.
If the verification times out, the change is automatically canceled, and the account reverts to its original state.
However, the platform’s logic is what you might call “thief-proof design”:
The moment you initiate an email change, the old email is immediately suspended (Suspended/Invalidated) by the system. However, the verification email sent to the new email address never even arrived because it was blocked by the email service provider.
And so, a magical deadlock ensued:
Old email: Frozen by the system; unable to log in.
New email: Did not receive the token; cannot be activated.
Result: The account is left hanging on both ends, effectively locked out, and there’s no “Cancel Change” or “Resend” option available on the front end for users who aren’t logged in.
Phase Two: Conflicting Email Addresses Leave Both AI and Human Support Stumped
Since the automated process has stalled, it’s time to contact customer support. But upon entering the ticket system, users are met by an AI bot that has absolutely no understanding of the system’s deadlock logic.
The AI support agent could only check the database status according to a preset script. Faced with an abnormal state like “old email suspended, new email not activated,” the AI support agent began endlessly repeating the same response. After finally managing to switch to a human support agent, an even more dramatic scene unfolded: the human support agent was also baffled.
After some troubleshooting, we discovered an even stranger logical conflict lurking in the underlying database:
The actual old account (containing adlink repository data): Its backend email was in a suspended “in-transition” state (and even the format of the originally linked primary email didn’t match expectations).
The new account I created while trying to fix the issue myself: It had inadvertently taken over my primary email (turning it into a shell account).
At this point, the solution was actually very clear:
Delete the newly created shell account -> Completely release the email address -> Clear the old account’s “Pending” status -> Rebind the old account to the primary email address.
Logically speaking, at this stage, the issue should have been resolved, right? However, the real architectural pitfall was just beginning.
The Final Showdown: A 304/403 Redirect Loop That Even Incognito Mode Can’t Save
After customer service deleted the newly created temporary account and reset and released the old account, I attempted to register and log in for the third time.
The moment I entered my username and password and clicked “Login,” the browser’s address bar began flashing frantically, and the page bounced back and forth between two URLs at millisecond speeds:
↳ (403 Forbidden)
↳ (304 Not Modified)
