We can go with CachedSelections.

why would we clear the user selection here?

We need to somehow clear siweBackupSecrets after persisting them to SQLite. Imagine the case when user registers, siweBackupSecrets is persisted to SQLite. Then the user logs out and logs in to another siwe account without closing the app in the process. In such case we would be keeping secret data for previous user in memory which sounds like a risk to me. Additionally it must be noted that siweBackupSecrets are the only data that we query for if the user is already logged in but they are missing. That said, keeping this data in memory between log out and log ins will make it harder to correctly detect if we should be forcing user to create the data or not.

Are we able to cache it, such that if the user goes back to before this screen, and then advances to this screen again, the SIWE flow does not need to be re-entered?

This code will not clear this data until they are persisted in SQLite, which will not happen until user becomes logged in (registration is complete). That said we can use this data in a way you described.

The effect below is somehow redundant so we can potentially remove it but its intention is the same - to prevent siweBackupSecrets from being kept in memory if the user logs out. We can either remove the effect below or remove setting to undefined above.

I think that my previous comment explains why this data receives special treatment. Agree that doing ENG-7389 would solve the problem. However we would need to solve it in this diff since unlike for other data in cachedSelections keeping siweBackupSecrets in memory could produce regressions.

Alternately, we could consider just setCachedSelections({})?

Open to doing it in this diff.

I will look into useRegistrationServerCall but two notes on this:

Avoids persisting to SQLite database which may be cleared prior to registration

1. This code prevents from persisting to SQLite before registration is completed and SQLite becomes stable.
2. We will eventually need some form of logic above for D11645. Potentially we could move it entirely to MissingRegistrationDataHandler but we will need something similar anyway.

I opted to extend this step instead of creating new one since both siwe backup secrets persistence and avatar upload require the same state of redux returned by hasCurrentUserInfo selector.

Here's the diff I referenced above: D11693

This was actually my first thought but then I noticed that we could probably access RegistrationContext directly to get other variables as well so I decided to introduce this additional layer of abstraction to meet the convention for other variables.

Ahhh, we probably can't since RegistrationContext exposes register property which is bound to useRegisterServerCall therefore we can't access it directly in useRegisterServerCall. Am I missing something?

Ah yes, you're right

Initially I was under the impression that this condition will protect us from SQLite database being deleted after siwe secrets are persisted. Now after looking at sqlite-data-handler.js code it looks like deletion is only triggered when database previously contained non-anonymous user id. So I think it is safe to put persistence call directly in returnFunc. I tested it and it works.

My initial idea was that it feels natural that clearing cached selections should be the last operation done here. If someone introduces new step after avatar upload that relies on cached selections they might forget about moving it. With separate step for clearing cached selections it is harder to overlook.