Firebase methods hanging

[bronze bluff]

I'm using both firebase sendSignInLinkToEmail (in action) and signInWithEmailLink (in loader) to authenticate users. Both functions hang forever, the promise never resolves or rejects.
Any ideas on the cause of this or where to start debugging ?
I'm on remix v1.16.1 firebase v10.3.1 and firebase-admin 11.10.1

[solemn quail]

Can you show some of the code? Otherwise it’ll be hard to diagnose any part of the problem

As for debugging tips, primarily you can just check if it’s definitely that function by doing a log before and after. But I’m not certain what else would make your app hang. It’s pretty odd for a network request to last anymore than a few seconds, at most like 30 seconds and it should throw an error

[bronze bluff]

here's the code for signInWithEmailLink it is being invoked in the loader function. I'm 100% sure it's hanging in the highlighted line using the method you mentioned (the "got user cred" msg never appears)

[solemn quail]

is that Firebase method not some kind of OAuth method? I believe the flow for OAuth stuff usually involves some kind of redirect from you to them back to you

I'm not 100% familiar with Firebase's approach here, but I do know that often times OAuth expects you to change the url a couple times during the whole flow, and I believe thats what the href is? It's saying take the user here after the authentication is done

[solemn quail]

But I could be mistaken there. But if I'm right thats probably why you're hanging, that signInWithEmailLink requires more input than an await directly.
Taking a look at their documentation it does seem to be the case. I believe firebase wants to be handled all on the front-end not through loaders and actions. You'd want either a client loader and client action (in newer versions of remix) or you'd want to move to react-router-dom itself to stay mostly similar to remix but use this oAuth

  // The client SDK will parse the code from the link for you.
  signInWithEmailLink(auth, email, window.location.href)
    .then((result) => {
      // Clear email from storage.
      window.localStorage.removeItem('emailForSignIn');

This line in their documentation kinda tells me they want to keep all the OAuth logic only in the front-end since window does not exist in the server. So I feel fairly confident you need to manage it all in the client

They also never explicitly call await on the signInWithEmailLink function, which tells me some other stuff is going on where it's expected to be running a long time with no real action. It might be opening a new tab and directing the user to do something there and listening for the server to respond back with a "good to go"

you also don't need to fully migrate to react-router-dom or anything, you can just handle it all on the client while still using remix, you just would need to not use loaders for it

but then you could setup an action to take a token and hold that in a cookie or something

[bronze bluff]

Thank you for taking the time to look at this.
The main problem here is that this code has been working as expected for the past few months it only broke recently out of the blue.
The methods I'm using are indeed intended for the client but that does not expalin why they decided to break now.
Most of my code is inspired from this video https://youtu.be/y1vzJ9nQQBs?t=449 but I'm using the passwordless methods instead (both are intended for client side but did work on the server side)
For the oAuth concern the function I shared is the last step in the process where we to the google identity provider the app creds (auth), the user email (email) and the action token (included in the current href) and the identity provider is supposed to respond with a user object or reject.

[bronze bluff]

I'll move signInWithEmailLink logic to the client side and see if this changes anything

[solemn quail]

Very strange it worked on the server and just stopped. Maybe a version bump in either remix or fire base changed things. Maybe you can change your version back?

[bronze bluff]

Very strange indeed, we did not change any of the versions.