Account creation is not atomic

[volovyks]

Occount creation on recovery and relayer sides is not atomic. Here is the descriptiuon of the situation taht happened with Vlad from @itegulov words:

Our mainnet deployment lost access to DB for half an hour or so (my fault for doing terraform shenanigans on testnet that accidentally messed up IAM configuration on mainnet, the new config value basically overwrote mainnet access). mpc-recovery registered your OIDC token with relayer and then tried to create an account for you - failed because it could not save the key in DB and thus never created an account for you. So, technically, your token is spent without an account being actually created. There is no way for us to "unregister" you from relayer so there is no rollback mechanism.

[volovyks]

The core issues is not connected to the DB directly, the core reason is that we can waste the token without actually creating an account. For example, here is one more scenario, more commen, where it can happen: https://github.com/near/mpc-recovery/blob/develop/integration-tests/tests/mpc/negative.rs#L208

[itegulov]

We can potentially solve this issue on our side by properly handling relayer response and proceeding with the regular flow if the account has already been registered on the relayer side. Not sure if relayer gives enough info in the error response, if not we should create an issue on their side.

[volovyks]

@itegulov looks like error handling will not help us here. We can handle an error from Relayer and continue the registration flow, but it will allow client to create multiple accounts per one Id Token.

The current error message from relayer looks like this:

Err { msg: "failed to process new account: fail: Error: oath_token test_issuer:jmrFqvUMu8 has already been used to register an account. You can only register 1 account per oath_token" }

If Relayer will return us the account_id that this token was associated with, we can handle this error and allow account creation on second attempt if the account id is the same. But, it will be a terible UX. User will need to enter the same account Id that was entered the first time.

The fundamental problem that we have here, is that account creation is a two step process on the relayer side.

[volovyks]

@anthony-near we discussed this before. It will be inconsistent with other relayer implementations, but it looks like we realy need to make account creation process atomic on the relayer side. Otherwise we will need to keep an additional DB and add a lot of unnecessary complexity.

Maybe we can introduce a third endpoint that will combine functionality of account registration and account creation on your side?