Unable to send from localhost (works on Vercel-hosted site)
See original GitHub issueI’m trying to use MailGun with a NextJS website and API routes. In the hosted site, the code works as expected and returns the “Queued. Thank you.” message.
On my local computer, when running using next dev
, I’m unable to get the messages.create(...)
function to work - it instead returns only
[Error] { status: undefined, message: undefined, details: undefined }
.
The code I’m using is given below (all of the environment variables can be logged and have values - the MG_API_KEY is taken from https://app.mailgun.com/app/account/security/api_keys (private API key) but I also tried generating and using a “Sending API Key” under https://app.mailgun.com/app/sending/domains/mydomainhere/sending-keys):
import Mailgun from 'mailgun.js'
import FormDataPackage from 'form-data'
const MG_API_KEY = process.env.MG_API_KEY as string
const mailgun = new Mailgun(FormDataPackage)
const mg = mailgun.client({ username: 'api', key: MG_API_KEY, url: 'https://api.mailgun.net' })
export type EmailContent = {
to: string | string[]
subject: string
bodyPlain: string
body?: string
from?: string
}
export const sendMailApi = async (emailContent: EmailContent) => {
const { to, subject, body, bodyPlain } = emailContent
const from = emailContent.from ?? process.env.EMAIL_FROM_MG
return mg.messages
.create('mydomainhere', {to, subject, text: bodyPlain, html: body, from})
.then((msg) => {
return msg
})
.catch((err) => {
return err
})
}
where ‘mydomainhere’ is the string taken from https://app.mailgun.com/app/sending/domains under “name”.
Is this expected behaviour, or should this work? Do I need to change some configuration detail when sending on localhost?
Issue Analytics
- State:
- Created a year ago
- Comments:5 (2 by maintainers)
Top GitHub Comments
It seems like this issue is more related to the local environment than to the SDK itself. Error handling was updated some time ago in version 7.0.1 So I am closing this issue. Feel free to open a new issue if you see places for improvement in this area. @chrisb2244, thank you for your input.
Sure - I’m using Windows Subsystem for Linux 2 with Docker containers to host a local development environment for my NextJS site, using a Docker engine directly inside WSL2 (not one installed in Windows, using e.g. Docker Desktop for Windows).
I suspect (although I haven’t tested) that if I used a Docker engine in the Windows OS, this might not happen, so it might be a corner case.
In any case, I installed Docker in WSL2 using something like
apt-get install docker-ce-cli docker-ce
, and then run the site using docker compose, shown below:I’m unsure if the bridge network might also be a contributing factor here. Previously I placed a database (using a mysql image) in the same compose file, but I’ve since replaced that. I’ll test after posting if removing the bridge network leaves me with a better/worse/unchanged situation.Removing the bridge network (and falling back on the default, which for Linux Docker is I believe just a different bridge) makes no difference.The Dockerfile probably doesn’t have anything unusual, it’s running from
node:16.13.0
, asUSER node
and the command isCMD ["npm", "run", "dev"]
.The triggering code I gave above is used in an API Route, at (in this case)
pages/api/sendMailTest.ts
.pages/api/sendMailTest.ts
This allows me to trigger the function by navigating to http://localhost:3000/api/sendMailTest, which is convenient for testing.
My updated
sendMailApi
function is copied below (but basically a variation on the one in a previous comment).lib/sendMail.ts
The problem can be resolved by adjusting the DNS nameservers produced by WSL on startup - more specifically, by default there is no file at
/etc/wsl.conf
, and/etc/resolv.conf
contains something like the following:Modifying it by following the instructions (add the wsl.conf file) and writing something like
allows emails to be sent (but can cause other issues with WSL, so it’s a bit fiddly - setting it like this prevents me from connecting to other systems via SSH or remote desktop within my workplace network). I think adding both lines might fix both issues, but I haven’t gotten around to finding a suitable way to generate and adapt the resolv.conf file on startup for that.