Wasp•4w ago

200 Response From Signup In Prod, But No Email

@kapa.ai After getting my app deployed on Fly, I am able to get to my landing page successfully via my custom domain and interact with the login and signup screens. However, when I register via email/password, I am not getting the registration email. In my console's network tab, I see a 200 response from https://xyz.app/auth/email/signup after I click the register button. The remote address in the request matches the IP of my Fly xyz-client app. I have already reset the MAILGUN_API_KEY and MAILGUN_DOMAIN on my Fly server app to make sure there we no typos, which I am using in my local development environment where I am able to receive the registration emails fine. In my Mailgun dashboard, I do not see any emails sent, bounced, or blocked. I am able to see the emails that sent in my development environment on my Mailgun dashboard fine. Provide me with a step by step troubleshooting checklist after carefully weighing all possible issues and what is most likely wrong.

21 Replies

kapa.ai•4w ago

Hi @SL8. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave: ---------------------- Certainly! Here’s a step-by-step troubleshooting checklist for your issue—registration emails not being sent in production, despite a 200 response from the signup endpoint and correct Mailgun credentials. This is based strictly on the Wasp documentation and related sources: --- 1. Confirm Email Provider Configuration in main.wasp Ensure your production deployment is using the correct email provider in your main.wasp file:

app Example {
  ...
  emailSender: {
    provider: Mailgun,
  }
}

app Example {
  ...
  emailSender: {
    provider: Mailgun,
  }
}

If you are using the Dummy provider, emails will only be logged to the console and not actually sent. The Dummy provider is for development only and will cause the build to fail in production, so make sure it is set to Mailgun for production use Docs: Providers. --- 2. Double-Check Environment Variables on Fly Verify that MAILGUN_API_KEY and MAILGUN_DOMAIN are set correctly in your production .env.server file on Fly. Typos or missing variables will prevent emails from being sent. The correct variables are:

MAILGUN_API_KEY=your-mailgun-api-key
MAILGUN_DOMAIN=your-mailgun-domain

MAILGUN_API_KEY=your-mailgun-api-key
MAILGUN_DOMAIN=your-mailgun-domain

Docs: Mailgun Provider --- 3. Restart the Server After Changing Environment Variables After updating environment variables on Fly, you must restart your server for the changes to take effect. If you haven’t done this, the app may still be running with old or missing values. --- 4. Check for Errors in Server Logs A 200 response from the signup endpoint only means the HTTP request succeeded. The actual email sending could still fail silently or be caught and logged as an error. Check your server logs for any errors related to email sending, such as authentication errors or network issues with Mailgun. --- 5. Confirm Email Verification Flow is Enabled Ensure that the email verification flow is properly configured in your main.wasp file, including the emailVerification field and the correct client route. If this is missing, the verification email may not be triggered Docs: Email Verification Flow. --- 6. Validate the From Address If you have customized the from field in your email sending logic, ensure it matches a verified sender in your Mailgun domain. Some providers (including Mailgun) may silently drop emails from unverified senders. --- 7. Test Email Sending in Production Try sending a test email directly from your production environment (e.g., via a simple script or Wasp action) to confirm that the Mailgun integration works outside of the signup flow. This can help isolate whether the issue is with the email provider setup or the signup logic. --- 8. Check Mailgun Dashboard for Suppression Even if you don’t see emails in the “Sent” tab, check Mailgun’s suppression lists (bounces, complaints, unsubscribes) to ensure your test email address isn’t blocked. --- 9. Review Custom Signup Logic (if any) If you have implemented a custom signup action, ensure that the call to sendEmailVerificationEmail is not being skipped or failing silently. Review your error handling to make sure any issues are surfaced Docs: Custom Signup Action. --- 10. Confirm No SKIP_EMAIL_VERIFICATION_IN_DEV in Production Make sure the SKIP_EMAIL_VERIFICATION_IN_DEV environment variable is not set to true in your production environment, as this would bypass the email verification step Docs: Email Verification Flow. --- If you follow these steps and still do not see emails in your Mailgun dashboard, the most likely issues are: - Incorrect or missing Mailgun environment variables in production. - The server was not restarted after updating environment variables. - Errors in the server logs related to email sending. - The Dummy provider is still being used in production. If none of these resolve the issue, please provide any error logs from your production server for further diagnosis. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @SL8, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?

SL8OP•4w ago

Hang on I think I figured it out - I forgot to set my OpenAPI env on the server so it was crashing 😭 @kapa.ai 1 - I have confirmed I am using Mailgun in main.wasp and I am able to recieve emails from my custom domain when running locally, so I know that's not the issue. I am testing on my local using the same environment variables set on my production Fly server, and I have already reset reset the MAILGUN_API_KEY and MAILGUN_DOMAIN on my Fly server app to make sure there we no typos 2 - See number one, I have done this 3 - I just did this on Fly for both machines, no luck 4 - The server logs contain no errors, nor any indication that registration flow was invoked. 5 - This flow works and I recieve the registration email as expected when running my Wasp app locally, so I believe I can rule this out 6 - See #5 response 7 - This is something I can try 8 - I have checked the mailgun dashboard and nothing is being blocked or suppressed. I can see the success logs from when my emails went out in my local testing. 9 - Does not apply 10 - I will try to set this environment variable on my production server to TRUE temporarily and see if I can get past the registration flow and into my app

kapa.ai•4w ago

Let me check the knowledge base for you again. One moment! :books: ---------------------- Thank you for the detailed follow-up. Based on your responses and the Wasp documentation, here are the most relevant next steps and considerations: --- Key Observations - You receive emails locally using the same environment variables, so Mailgun credentials and domain are correct. - No errors or registration flow logs appear in your production server logs. - Changing environment variables and restarting the server did not help. - The registration flow works locally but not in production. --- Focused Troubleshooting Steps #### 1. Confirm the Production Build Is Using the Correct Code and Config Wasp generates all deployable code in the .wasp/build directory. If your production deployment is not picking up the latest code or environment variables, it could explain why the registration flow is not invoked. Double-check that your deployment process is building and deploying the latest code and that the .env.server file is present and correct in the production environment (Discord: see deployed code). #### 2. Check for Missing or Incorrect Environment Variables at Runtime Even if you set the environment variables on Fly, verify that they are actually available to the running process. You can do this by adding a temporary log statement in your server code to print out process.env.MAILGUN_API_KEY and process.env.MAILGUN_DOMAIN (be careful not to expose secrets in logs). This will confirm that the environment is set up as expected at runtime (Env Vars Docs). #### 3. Ensure the Email Provider Is Not Falling Back to Dummy Wasp will fail the build if you try to use the Dummy provider in production, but if for some reason the emailSender config is not being picked up, or if the build is using an old config, the email sending logic might not be triggered at all (Email Providers). #### 4. Test the Email Sending Logic Directly in Production As you mentioned, try sending a test email from your production environment outside of the registration flow. This will help isolate whether the issue is with the email sending setup or with the registration flow not being triggered. #### 5. Temporarily Set SKIP_EMAIL_VERIFICATION_IN_DEV=true Setting this environment variable to true in production (temporarily) will allow you to bypass the email verification step and see if the rest of the registration flow works. If you can register and log in, it suggests the issue is isolated to the email sending step (Email Verification Flow). #### 6. Inspect the Network and Application Logs Since you see a 200 response from the signup endpoint, but no logs on the server, ensure that the request is actually reaching your server and not being intercepted or misrouted (e.g., by a proxy or misconfigured route). You can add additional logging at the entry point of your signup handler to confirm invocation. --- Summary Based on the Wasp documentation and your troubleshooting so far, the most likely issues are: - The production environment is not picking up the correct environment variables or code. - The registration/signup handler is not being invoked in production. - There is a deployment or routing issue preventing the request from reaching the server. If after these steps the issue persists, please provide any additional logs or details from your production environment, especially around the deployment process and environment variable setup. If you need more specific guidance on how to log or test these steps in Wasp, let me know! ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @SL8, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?

SL8OP•4w ago

@kapa.ai If I set SKIP_EMAIL_VERIFICATION_IN_DEV=true on my prod server and I am still seeing the You've signed up successfully! Check your email for the confirmation link. popup after clikcing Sign Up, what does that lead you to think?

kapa.ai•4w ago

Let me check the knowledge base for you again. One moment! :books: ---------------------- If you set SKIP_EMAIL_VERIFICATION_IN_DEV=true on your production server and are still seeing the popup message “You've signed up successfully! Check your email for the confirmation link.” after clicking Sign Up, this suggests that the environment variable is not being picked up by your production server at runtime. According to the Wasp documentation, setting SKIP_EMAIL_VERIFICATION_IN_DEV=true should cause the app to skip the email verification step in development, allowing users to log in immediately after signup without needing to check their email. If this variable is set but the UI still prompts users to check their email, it likely means: - The environment variable is not set correctly or is not available to the running process in production. - The server may need to be restarted after setting the variable for it to take effect. - There could be an issue with how environment variables are loaded or accessed in your production deployment Docs: Email Verification Flow. The knowledge sources do not mention any other reasons for this behavior, so the most probable cause is that the environment variable is not being recognized by your production server. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @SL8, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?

SL8OP•4w ago

@kapa.ai I have already restarted both the client and the server machines. I'm not really sure where to go from here

kapa.ai•4w ago

Let me check the knowledge base for you again. One moment! :books:

MEE6•4w ago

Wohooo @SL8, you just became a Waspeteer level 3!

kapa.ai•4w ago

---------------------- Given that you have already restarted both the client and server machines, and setting SKIP_EMAIL_VERIFICATION_IN_DEV=true on your production server did not change the signup behavior, the most likely issue is that your production server is not picking up the environment variable as expected. The Wasp documentation emphasizes that environment variables must be set in the environment where the server process is running, and that the way you provide them in production depends on your deployment platform. For Fly.io, you should use the flyctl secrets set command to set environment variables for the server, for example:

flyctl secrets set SKIP_EMAIL_VERIFICATION_IN_DEV=true

flyctl secrets set SKIP_EMAIL_VERIFICATION_IN_DEV=true

After setting the secret, you must restart the server for the new value to take effect (Defining Env Vars in Production). If you have already done this and it still does not work, it suggests that: - The environment variable is not being set in the correct environment (e.g., it might be set on the client instead of the server). - There may be a typo in the variable name or value. - The server process is not actually using the updated environment (for example, if the deployment did not fully restart the process). The knowledge sources do not provide further troubleshooting steps for this specific scenario. If you have confirmed the above and the issue persists, you may want to add logging to your server code to print out the value of process.env.SKIP_EMAIL_VERIFICATION_IN_DEV at runtime, to verify what the server actually sees. This can help confirm whether the variable is being set as expected. If this does not reveal the issue, the knowledge sources do not contain enough information to provide a more specific answer. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @SL8, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?

SL8OP•4w ago

@kapa.ai Could this indicate that the client is not communicating with the server properly? If so, what could I double check there?

kapa.ai•4w ago

Let me check the knowledge base for you again. One moment! :books: ---------------------- Yes, this could indicate that the client is not communicating with the server properly, or that the client is communicating with a different server/environment than you expect. Here are some things you can double-check, based on the knowledge sources: 1. Client-Server URL Configuration:
Make sure your client is configured to send requests to the correct server URL in production. If the client is still pointing to a local server or an incorrect address, it may not be reaching your deployed backend at all. You can set the server URL for the client as described in the docs and Discord threads. For example, you may need to set REACT_APP_API_URL in your .env.client file to point to your production server URL, and ensure this is embedded at build time (Discord: CORS and API URL, Docs: Deployment - Web Client). 2. Network Tab in Browser Dev Tools:
Open your browser’s dev tools and check the Network tab to see where the signup request is being sent. Confirm that the request is going to your production server and not to localhost or another unintended address (Discord: AxiosError). 3. Server Logs:
If the server logs do not show any indication that the registration flow was invoked, it suggests the server is not receiving the request. This could be due to a misconfigured client-server connection or a deployment/networking issue. 4. CORS Issues:
If the client and server are on different domains or ports, ensure CORS is configured correctly on the server. CORS issues can silently block requests from reaching your backend (Discord: CORS Issue). 5. Environment Variables Embedded at Build Time:
Remember that client environment variables (like API URLs) are embedded at build time. If you change them after building, you need to rebuild and redeploy the client (Docs: Env Vars). If after these checks the client is still not communicating with the server, you may want to add temporary logging or alerts in both the client and server to confirm the flow of requests and responses. If the client is not reaching the server, fixing the API URL or CORS configuration is often the solution. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @SL8, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?

SL8OP•4w ago

@kapa.ai I just realized that the remote address of my network request to https://xyz.app/auth/email/signup points to my Fly client app, not my Fly server app. Is that expected?

kapa.ai•4w ago

Let me check the knowledge base for you again. One moment! :books: ---------------------- No, that is not expected. The /auth/email/signup endpoint is handled by your Wasp server (backend), not the client (frontend). Your client app should be making API requests (such as signup, login, etc.) to the server app's URL, not to the client app's URL. If the network request is going to your Fly client app, it means your client is configured to send API requests to itself, rather than to the backend. This misconfiguration would explain why your server logs show no registration activity and why environment variable changes on the server have no effect. You should double-check the value of REACT_APP_API_URL (or the equivalent API URL configuration) in your client environment. It must point to your Fly server app's URL (e.g., <https://your-server-app.fly.dev>), not your client app's URL. This is described in the Wasp documentation for accessing app config and deploying the web client (Client configuration object, Deploying the web client). After updating the API URL, rebuild and redeploy your client so the correct server address is embedded in the frontend code. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @SL8, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?

SL8OP•4w ago

@kapa.ai Should I still point it to a .fly.dev address if I am using a custom domain?

kapa.ai•4w ago

Let me check the knowledge base for you again. One moment! :books: ---------------------- If you are using a custom domain for your app, you should point REACT_APP_API_URL to the custom domain that resolves to your server (backend) app, not the default .fly.dev address. The important thing is that the API URL matches the public address where your backend is accessible to the client/browser. For example, if your server is available at <https://api.xyz.app,> then REACT_APP_API_URL should be set to <https://api.xyz.app.> If you are still using the .fly.dev address for your backend, then you would use that. But once your custom domain is set up and points to your backend, use the custom domain. This is consistent with the Wasp documentation, which states that in production, the client’s apiUrl should contain the value of your server’s URL as the user's browser sees it (i.e., with DNS and proxies considered) (Client configuration object). So, use your custom domain for REACT_APP_API_URL if your backend is accessible via that domain. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @SL8, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?

SL8OP•4w ago

@kapa.ai I found my issue. I was setting REACT_APP_API_URL=https://xyz.app instead of REACT_APP_API_URL=https://xyz-server.fly.dev Thanks.

kapa.ai•4w ago

Let me check the knowledge base for you again. One moment! :books: ---------------------- Great job identifying the issue! According to the Wasp documentation, the REACT_APP_API_URL environment variable in your client build must point to the actual URL of your backend server—the address where your Wasp server (API) is deployed and accessible from the browser. If you set it to your frontend's domain (e.g., <https://xyz.app>), the client will attempt to send API requests to itself, which will not work since the frontend does not handle those endpoints. Instead, it should be set to your backend's URL (e.g., <https://xyz-server.fly.dev> or your custom backend domain if you have one) Client configuration object Deploying the web client. After updating REACT_APP_API_URL to the correct backend address, remember to rebuild and redeploy your client so the new value is embedded in your frontend code. This should resolve the issue with API requests not reaching your server. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @SL8, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?

Kynetix•6d ago

@kapa.ai When I sign up using an email address, it doesn't send the verification email, and I get the Mailgun error "File not found". It doesn't specify which file is missing, and I'm not sure how to start troubleshooting it. Here's the terminal message: Failed to send email [Error: Not Found] { [ Server!] status: 404, [ Server!] details: '404 page not found\n', [ Server!] type: 'MailgunAPIError' [ Server!] }

kapa.ai•6d ago

Let me check the knowledge base for you again. One moment! :books: ---------------------- The error message from Mailgun, "File not found" with a 404 status, typically means that the Mailgun API endpoint your app is trying to reach does not exist or is incorrect. In the context of Wasp, this usually points to a misconfiguration in your Mailgun setup, most likely with the MAILGUN_DOMAIN environment variable. Based on the Wasp documentation, here are the steps you should take to troubleshoot: 1. Check MAILGUN_DOMAIN Value:
Ensure that the MAILGUN_DOMAIN in your .env.server file matches exactly the domain provided by Mailgun. It should look something like sandbox12345.mailgun.org or your custom Mailgun domain. A typo or an incorrect domain (such as including <https://> or omitting part of the domain) will cause Mailgun to return a 404 error Using the Mailgun Provider. 2. Check MAILGUN_API_KEY:
Make sure your MAILGUN_API_KEY is correct and active. An invalid API key can also cause Mailgun to return errors, though usually a 401 rather than a 404. 3. Restart Your Server:
After updating environment variables, restart your server to ensure the new values are loaded. 4. No File Attachments Expected:
The Wasp email sending flow for verification does not require you to attach files, so the "File not found" is not about an attachment, but about the API endpoint. 5. Check for Typos in main.wasp:
Make sure your emailSender configuration in main.wasp is set to use Mailgun and not another provider, and that there are no typos in the provider name or config Docs: Email Sender. If after these checks you are still seeing the error, the knowledge sources do not provide further details on Mailgun-specific 404 errors. In that case, double-check your Mailgun dashboard for the correct domain and API key, and ensure your environment variables are set exactly as required. If you need to see how to set these variables, refer to the example in the docs:

MAILGUN_API_KEY=your-mailgun-api-key
MAILGUN_DOMAIN=your-mailgun-domain

MAILGUN_API_KEY=your-mailgun-api-key
MAILGUN_DOMAIN=your-mailgun-domain

Using the Mailgun Provider If you continue to have issues, please provide the exact value (with sensitive info redacted) you are using for MAILGUN_DOMAIN. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Kynetix, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?

Kynetix•6d ago

@kapa.ai I believe the mailgun setup is correct because I use it throughout the application for other things (sending notifications, welcome messages, etc). Does the verification feature use a different setup from the regular email sending?

kapa.ai•6d ago

Let me check the knowledge base for you again. One moment! :books: ---------------------- Based on the Wasp documentation, the email verification feature uses the same email sending setup as other email-sending features in your application. Both the verification emails and other types of emails (like notifications or welcome messages) rely on the emailSender configuration in your main.wasp file, which specifies the provider (e.g., Mailgun) and related settings Using the Mailgun Provider. There is no indication in the knowledge sources that the verification feature uses a different Mailgun setup or configuration from regular email sending. If other emails are working but verification emails are not, the issue is likely not with the Mailgun setup itself, but could be related to how the verification email is being triggered or constructed. If you are seeing a "File not found" error only for verification emails, double-check the logic or content generation for those emails, but the underlying email provider configuration is shared across all email-sending features in Wasp Docs: Email Sender. If you need to customize the content of verification emails, you can do so via the getEmailContentFn option, but this does not affect the provider setup Docs: Email Verification Config. If you need more specific troubleshooting, please provide details about how you are triggering the verification email versus other emails. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Kynetix, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?

Gaming

Programming

200 Response From Signup In Prod, But No Email

Did you find this page helpful?