backup.rs:82-87 says it plainly: creating a key always registers a brand new backup version rather than checking for or reusing an existing one, and deleting the old version is "a follow-up, not handled here".
So pressing "Create a new recovery key" twice leaves an orphaned version on the server holding keys the new key cannot read, and the old recovery key silently stops corresponding to the live backup.
Done looks like: check for an existing version first and either reuse it or delete it after a successful migration.
`backup.rs:82-87` says it plainly: creating a key always registers a brand new backup version rather than checking for or reusing an existing one, and deleting the old version is "a follow-up, not handled here".
So pressing "Create a new recovery key" twice leaves an orphaned version on the server holding keys the new key cannot read, and the old recovery key silently stops corresponding to the live backup.
**Done looks like:** check for an existing version first and either reuse it or delete it after a successful migration.
Making a new recovery key registered a new backup version and left the old one on the server — still valid under the old key, still holding room keys the new one cannot read, and no longer receiving anything. Somebody with the previous key written down would find it restored a partial history and then stopped, with nothing saying why.
The previous version is now deleted after the new one is registered, and the order is deliberate: deleting first would leave an account with no backup at all if registering the replacement then failed, which is the one outcome worse than having two.
A failed delete is not a failed setup. The new backup works, and refusing to hand over a working recovery key because the server is left untidy would be the wrong trade — so it warns with both version numbers and carries on. The version that gets replaced is read before anything is changed, so it is the one that existed when the request was made rather than whatever is there by the time the delete runs.
Finished — https://git.salastil.com/Salastil/nobilis/commit/3ec9d34
Making a new recovery key registered a new backup version and left the old one on the server — still valid under the *old* key, still holding room keys the new one cannot read, and no longer receiving anything. Somebody with the previous key written down would find it restored a partial history and then stopped, with nothing saying why.
The previous version is now deleted after the new one is registered, and the order is deliberate: deleting first would leave an account with **no** backup at all if registering the replacement then failed, which is the one outcome worse than having two.
A failed delete is not a failed setup. The new backup works, and refusing to hand over a working recovery key because the server is left untidy would be the wrong trade — so it warns with both version numbers and carries on. The version that gets replaced is read before anything is changed, so it is the one that existed when the request was made rather than whatever is there by the time the delete runs.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
backup.rs:82-87says it plainly: creating a key always registers a brand new backup version rather than checking for or reusing an existing one, and deleting the old version is "a follow-up, not handled here".So pressing "Create a new recovery key" twice leaves an orphaned version on the server holding keys the new key cannot read, and the old recovery key silently stops corresponding to the live backup.
Done looks like: check for an existing version first and either reuse it or delete it after a successful migration.
Finished — https://git.salastil.com/Salastil/nobilis/commit/3ec9d34
Making a new recovery key registered a new backup version and left the old one on the server — still valid under the old key, still holding room keys the new one cannot read, and no longer receiving anything. Somebody with the previous key written down would find it restored a partial history and then stopped, with nothing saying why.
The previous version is now deleted after the new one is registered, and the order is deliberate: deleting first would leave an account with no backup at all if registering the replacement then failed, which is the one outcome worse than having two.
A failed delete is not a failed setup. The new backup works, and refusing to hand over a working recovery key because the server is left untidy would be the wrong trade — so it warns with both version numbers and carries on. The version that gets replaced is read before anything is changed, so it is the one that existed when the request was made rather than whatever is there by the time the delete runs.