oauth logic trap

Here's an interesting issue for folks moving from testing with simple email/password login to adding google/apple/etc oauth.

We have an app that sets several user fields (not just email, etc) on account creation. We have an auth_createAccount page and an auth_login page. There are, in particular, two fields in users collection that we add at creation and set app state variables. These are important for the proper functioning of the app. (We do have good error handling in case those app state variables turn up null.)

Because setting these fields is important, we've been setting them in the lower section of the auth action of the "Create Account" button. That way, there is less chance of the app failing between creation and going to another page where the user sets profile information. (Note: we originally did it this way, completing basic account creation and then home page sending the user to editProfile page if key fields weren't set.)

This was working fine for us...until we started adding google oauth login, which -- for reasons I just don't get -- has a toggle that creates a users collection document if there isn't one. This makes complete sense under oauth 'create account' action, but in login, this spells trouble, because a user that doesn't have an account but chooses login rather than create account from the welcome page will actually create an account and a user record...BUT without adding the necessary extra fields we set in auth_createAccount page.

Conversely, if a user who already has an account (and may have forgotten) goes to create account and hits the google button, the actionflow required for new users will log them in...BUT will add/replace the user's original fields, blowing out any changes the user had made before. Not good.

This HAS to be a really common issue.

We have two or three ways to handle this, but none of them are elegant. For example, we can run a check during login that checks for whether the users document doesn't have the required fields set (indicating they are a new user) and then send them to a special extra createProfile page that allows them to set their data before proceeding to home page. We can also strip the users document field setting process in the auth action in createAccount and then run a check on whether the user already has data in their fields, in which case further create account actions will stop, and the user will be sent to home page directly -- we can add the required fields in a subsequent update document action if they truly are a new user.

Or we can take new user field setting process out of account creation altogether and go back to testing for unset fields in the page-load action flow of home (and send them to editProfile if necessary fields aren't there). But this is also not elegant.

Thoughts?