auth0 / node-auth0

Node.js client library for the Auth0 platform.
MIT License
633 stars 309 forks source link

Passwordless SMS and email not sending reliably #972

Closed fredrik-sogaard closed 10 months ago

fredrik-sogaard commented 10 months ago

Checklist

Description

We're using the passwordless.sendSMS and passwordless.sendEmail methods to send codes from a Node server, and it works very unreliably. Locally it works for a while, and stops working. Deployed to Vercel it almost never works.

We can consistently get I to work with new emails and new phone numbers, but existing Auth0 users sometimes get codes.

No errors are returned from the methods themselves, Auth0 logs or Twilio logs. In fact the Auth0 logs don't show anything: no errors, not sent code logs, nothing.

I don't think we're hitting any rate limits as we are only testing this amongst max 4 people.

We've checked all we can check both on Auth0 and our code, but are really at loss here. Very hard to figure out since it works sometimes, and no errors to be found.

Any ideas of what this could be?

Reproduction

Very hard...

Additional context

No response

node-auth0 version

4.1.0

Node.js version

18.12.1

frederikprijck commented 10 months ago

👋 Thanks for reaching out. Can you clarify if the SDK is being unreliable, or the API side?

In case of the API side, I recommend you to reach out to your account manager, as they can raise this with the proper teams. From the SDK side we can not change any reliability of the API.

If this would be an SDK specific problem, please let us know how we can reproduce this (can you share a sample that shows how our SDK behaves differently from calling the API's directly?)

frederikprijck commented 10 months ago

Closing, as there isnt any more information provided. Feel free to ping is we should reopen.

fredrik-sogaard commented 9 months ago

After a lot of investigation, we think the culprit is Next JS 14 Server Actions and how they cache these. It seems that the same input into a server action, generates the same cached response, and the request never even got to Auht0's API. We have temporarily fixed it by sending some random uid to the action to force a new request. Weird.