mirror of
https://github.com/stack-auth/stack.git
synced 2026-06-13 21:01:21 +08:00
fa360aba9c
### Context Some of our users' emails were getting stuck in sending. The long delays in processing the retries caused a vercel function timeout. ### Summary of Changes We refactor the low level email sending functions to remove the retry logic there. We kick it up to the email queue step. Additionally, we flag emails to be retried when they encounter issues but leave it for a future iteration to actually perform the retry. We perform an exponential backoff with a random component to decide when they have to be retried. We also make some small adjustments to the queuing function to not queue skipped emails. When an email fails to send during the sending function, we check to see if it is a retryable error or not. Some errors are transient and trying again may succeed while others indicate deeper issues. If it is retryable, and the max number of retry attempts hasn't been reached, we set `nextSendRetryAt` to a time determined by an exponential backoff calculation function. When the queuing function looks for emails to queue, it doesn't just pick up the `SCHEDULED`. emails whose `scheduledAt` time <= `NOW()`, but also those emails whose `nextSendRetryAt` time <= `NOW()`. What this means in practice is that one iteration of the `email-queue-step` will mark emails as retryable while another iteration will perform the retry. This should be cleaner and prevent long delays in the `email-queue-step` process due to retries. This also makes it easier to scale up the number of retries if need be. |
||
|---|---|---|
| .. | ||
| prisma | ||
| scripts | ||
| src | ||
| .env | ||
| .env.development | ||
| .eslintrc.cjs | ||
| .gitignore | ||
| instrumentation-client.ts | ||
| LICENSE | ||
| next.config.mjs | ||
| package.json | ||
| prisma.config.ts | ||
| tsconfig.json | ||
| vercel.json | ||
| vitest.config.ts | ||
| vitest.setup.ts | ||