Encountered a 504 - request timed out error while performing auth tasks (e.g., sending recovery or magic links) in a self-hosted Supabase Studio

[rafadlis]

Specs

Spec	detail
OS	Ubuntu Server
Main Tools	aapanel
Supabase Deployment	Docker
Mail Server	Mail Server aapanel (tested)

SMTP config

the SMTP server is running fine but it takes quite a while to send an email.
 

the logs

Event Message

{
  "auth_event": {
    "action": "user_recovery_requested",
    "actor_id": "03016027-3423-4c7e-b262-6a8cac8e8594",
    "actor_username": "[email protected]",
    "actor_via_sso": false,
    "log_type": "user"
  },
  "component": "api",
  "error": "context deadline exceeded",
  "level": "error",
  "method": "POST",
  "msg": "504: Processing this request timed out, please retry after a moment.",
  "path": "/recover",
  "referer": "http://localhost:3000",
  "remote_addr": "172.19.0.12",
  "request_id": "e180d34f-af64-4e10-acb5-f6fdf2d773bb",
  "time": "2024-10-28T22:47:16Z"
}

metadata

[
  {
    "auth_event": [
      {
        "action": "user_recovery_requested",
        "actor_id": "03016027-3423-4c7e-b262-6a8cac8e8594",
        "actor_username": "[email protected]",
        "actor_via_sso": false,
        "log_type": "user"
      }
    ],
    "component": "api",
    "error": "context deadline exceeded",
    "level": "error",
    "method": "POST",
    "msg": "504: Processing this request timed out, please retry after a moment.",
    "path": "/recover",
    "referer": "http://localhost:3000",
    "remote_addr": "172.19.0.12",
    "request_id": "e180d34f-af64-4e10-acb5-f6fdf2d773bb",
    "time": "2024-10-28T22:47:16Z",
    "timestamp": "2024-10-28T22:47:16Z"
  }
]

The Questions

How can I extend the request timeout duration? Are there any alternative solutions to address this issue?

[abdrhxyii]

Did you fix the issue ?. Im also having the same issue.

[rafadlis]

My proposed solution is to switch the mail server to resend.com and use different domain, configure it using .env settings as outlined in Resend's documentation:

resend.com/docs/send-with-supabase-smtp

However, I haven't been able to find a solution and don't have enough time to debug it.

[rafadlis]

My biggest hypothesis is that there might be an issue with the .env configuration I set or the domain I used

[carbonkel525]

If you using resend, keep the configuration as in the docs. Only put your port to 587. It worked for me.

[rafadlis]

If you using resend, keep the configuration as in the docs. Only put your port to 587. It worked for me.

I will try this, thanks for the answer

[carbonkel525]

Let me know if it worked

[carbonkel525]

Having the same problem here, using a self-hosted supabase instance via coolify. I set all the .env variables in the coolify dashboard for using the resend smtp server. SMTP_HOST=smtp.resend.com, SMTP_PASS=my_resend_api_key, SMTP_PORT=465, SMTP_USER=resend

When inviting a user in the auth>Users page in my self-hosted supabase instance, I get a 504 error in the console with message: Processing this request timed out, please retry after a moment.

[abdrhxyii]

I'm having this for 1 week, couldn't fix it yet.

[carbonkel525]

I tried the default coolify smtp port SMTP_PORT=587 and it solved my issue. I don't know why resend is telling us to use SMTP_PORT=465.
Invite email and password recovery works great now.

[carbonkel525]

To make it more clear SMTP_HOST=smtp.resend.com, SMTP_PASS=my_resend_api_key, SMTP_PORT=587, SMTP_USER=resend, ENABLE_EMAIL_AUTOCONFIRM=true, ENABLE_EMAIL_SIGNUP=true try to set your .env vars like this. Then go to your supabase instance and try to invite a user. It should work

[rafadlis]

I'm having this for 1 week, couldn't fix it yet.

If the @carbonkel525 solution isn't working, try changing the domain. It might help. Also, check the domain configuration and health for any issues.

[kyleorin]

having the same issue with zeptomail not entirely sure if im doing something wrong or its simply not working

[ewann]

fwiw: I just encountered similar / same situation, that was confirmed not the case as recently as yesterday. Below configuration resolved my incident:

Where as 465 had been configured for ~6 weeks previous without being an issue.

https://resend.com/docs/send-with-smtp captures the info:

and https://resend.com/docs/send-with-supabase-smtp still instructs to use 465. Looking at the previous comments in this discussion, I suppose there is some rolling infrastructure change on supabase side that is getting deployed across all envs? I'm in eu-west-2 / London; perhaps interestingly there is currently a maintenance window advertised, although it allegedly doesn't impact my region

🤷‍♂️