EDIT: actually not sure why this is even here. Leaving the comment below in case you decide to keep it, but it's not clear to me why this change is necessary.

You're introducing a big risk here. If linkFID fails it will leave the registration is a partially-successful state, and won't delete the resultant identity account. As a result, if the user retries after this failure, they will get a second error that the username is already taken.

They'll also be using the same private keys to attempt to register two different identity accounts, which would be a problem if the user backs out and changes the username, and retries to register account. It will succeed and result in two different identity accounts with the same keys.

Can you wrap this in a try-catch that:

1. Shows an error message if it fails. If it fails due to the Farcaster account already being linked, let's show the same error text that I introduced in D11862 (should probably be factored out into alert-messages.js)
2. Runs this code to clear the identity account, both locally and on the identity service:

void dispatchActionPromise(
  deleteAccountActionTypes,
  discardIdentityAccountPromise,
);
await waitUntilDatabaseDeleted();

See how it works in the effect later in the file. Also you'll need to make sure that waitUntilDatabaseDeleted finishes before you reject the promise.

Should probably be renamed since failure can now still occur

What is the point of this onSuccess function now? Can it be deleted? (Probably not if you take my above advice)

What happens on failure? If it fails because the FC account is already linked, let's show the same error text I introduced in D11862 (should probably be factored out into alert-messages.js). It it fails otherwise, we can use UnknownErrorAlertDetails

We probably also need to call setWebViewState('closed') on failure. By the way, why aren't we calling it on success?

Error-handling needed here too

Are we making sure the in-progress state is reflected well in the UI? When does the bottom sheet get dismissed? When does the spinner in the button stop spinning?

Can we rename this to tryLinkFID or something? The naming is confusing and I think the functionality of this function gets more clear once setWebViewState is removed from here

I’m not sure this needs to be factored out. I think it makes things more complicated than they need to be. Can we leave this part to be handled by the component that calls this hook?

You need getMessageForException. I think this code can crash if somebody throws a non-object