Start with the deployed history.
The 1.7.3 account change restores the provider-based identity contract. A database that remained on the 1.6 core account schema has a different starting point from one that applied the temporary issuer-based schema in 1.7.0–1.7.2. The current official guide distinguishes these paths. Plugin-specific migrations can still apply.
| Observed starting point | What to establish |
|---|---|
| 1.6 account table, no issuer migration | Check duplicate provider/account keys and the other changes relevant to your plugins. Do not add an issuer column just because an older discussion says to. |
| 1.7.0–1.7.2 issuer schema applied | Review the issuer index and column constraints, ORM schema, duplicate target keys and provider configuration before cutover. |
| History unknown | Read deployment and migration records, then inspect a restored database. An installed package version does not settle the schema history. |
Keep three separate observations.
Rows: which account records share a target key? Schema: can the new package insert the fields it writes? Runtime: does a real login return the intended user? The identity map answers a bounded part of the first question. Schema notes only record what you have checked elsewhere. The final question needs a staging login.
For example, the demonstration has three rows, but two share the same provider and subject. Their different issuer labels separate them in the old map. In the target map they meet at one central node. No amount of changing a column from required to optional decides which person that key should identify.
What our real-version test established.
We created an account using the published 1.7.2 package and an in-memory SQLite database. Initializing 1.7.3 against the unchanged required-issuer schema produced a schema mismatch. After applying the corresponding cleanup in the disposable database, the old account signed in with the same user ID and a new signup succeeded. This is one concrete reproduction, not a guarantee for every adapter or production dataset.
Before choosing a rollback.
Keep the data recovery plan with the release plan. A package downgrade can leave newer rows with a shape the old version cannot use. Test recovery on the restored copy and consult the current guide before reopening writes; KeyFold does not generate or execute migration commands.
Sources: maintainer explanation, September 7, 2026; current 1.7 upgrade guide. Our reproduction and scope.
Follow the three-row collision ↗