Schedule email with sendgrid
According to the api of sendgrid you can schedule emails via the
send_at header: https://docs.sendgrid.com/for-developers/sending-email/building-an-x-smtpapi-header#scheduling-your-send
But this sadly does not seem to be possible using the wasp's emailSender api: https://wasp-lang.dev/docs/advanced/email#javascript-api. Is there a nice and clean workaround or is it planned to add more headers to the emailSender api?39 Replies
looks likethe docs you mention explain that you should place:
x-smtpapi: {"send_at":"[when you want to send the mail]"}
before the "from:" line in that email
like this:
import { emailSender } from "@wasp/email/index.js";
// In some action handler...
const info = await emailSender.send({
x-smtpapi: {"send_at":"[when you want to send the mail]"}
from: {
name: "John Doe",
email: "john@doe.com",
},
to: "user@domain.com",
subject: "Saying hello",
text: "Hello world",
html: "Hello <strong>world</strong>",
});
the
emailSender seems to ignore properties not mentioned in their API. Also the typescript implementation does not accept any other properties (although i tried to ignore this by defining it as any.You’ll probably want to do it the easy way and just replace that function with the twilio node package. https://docs.sendgrid.com/for-developers/sending-email/quickstart-nodejs
Email API Quickstart for Node.js to Send Email
Sending your first email using the SendGrid REST API and Node.js.
hmm you could always create a queue via Wasp Jobs and use the
delay() method: https://wasp-lang.dev/docs/advanced/jobs
you can pass delay the number of seconds, Date, or ISO date string
your email sending logic would be a function you reference in your wasp file, then you'd import the job and pass the arguments to it with the delay you want:
@Gwaggli it would be nice if we had support for these extra fields, you are right, thanks for this feedback! We already have an issue for this: https://github.com/wasp-lang/wasp/issues/1553 -> I added your comment there also now.
We will be looking into this at some point, it is not currently at the top list of our priorities, but once we are going to be working again on email sender, then we will see how to work this in.
Thank you both! i will try the delay approach in the meantime 🙂
I tried to use scheduled Jobs to get the job done but now I have another issue: When I first start the app after restarting my Mac the app starts normally (after starting the db) but once I restart the app (
wasp start) again, it fails saying: [Server!] pg-boss failed to start! Error: connect ECONNREFUSED ::1:5432 even tho my database is running on that port.
Any idea why this might occur?
And one additional question. When I have console.log statements inside the job (hosted on fly.io) should I see those logs in the monitoring as well or is this written somewhere else?Hmm I think maybe @miho knows something about this
Are you sure your db is running?
And yes you’ll see the logs in monitoring on fly
Yes as the app starts the first time after booting up the pc and only after changing the source code and thus recompiling i get this error message.
Logs should be written in the same machine, as Jobs are running on that same machine.
pg-boss connection refused -> that sounds like a possible issue! Maybe pg-boss doesn't disconnect gracefully in that situation?
Just to clarify some things:
1. Does this happen when you change stuff in source files and
wasp start restarts itself, or when you kill wasp start and then start it again yourself?
2. How do you fix it once it happens?1. Yes it happens when wasp itself restarts on source file changes. But after that also happens if i manually restart the process.
2. I was not yet able to fix it other than by restarting my machine. As I am not familiar with pg-boss I did not really know where to start looking.
Ok thanks @Gwaggli , we will create an issue for this and look it up for sure! I might get back to you in a couple of days with more questions if I don't manage to reproduce it.
Thank you! Happy to assist 🙂
So I created issue for this here to track it https://github.com/wasp-lang/wasp/issues/1605 . Some additional questions:
1. What happens if you restart the database? I guess that also fixes the problem?
2. How are you running the db? On your own or with
wasp start db?GitHub
Pg-boss connection · Issue #1605 · wasp-lang/wasp
When I first start the app after restarting my Mac the app starts normally (after starting the db) but once I restart the app (wasp start) again, it fails saying: [Server!] pg-boss failed to start!...
Thank you!
Should i respond here or in the issue itself?
1. No restarting the DB does sadly not fix the problem.
2. I normally start the db with
wasp db start but wasp start db has the same outcome I just realised. I stop the DB by ctrl+c.Oh wow restarting the DB doesn't help but restarting Mac does -> ok that is quite weird. That sounds like there is maybe some process remaining running? Hmm pretty weird! But this is important to know, thanks.
You can write here or on issue, both is fine -> I will transfer this info to the issue now.
And yes
wasp start db and wasp db start are aliases, they do the same thing :).Yes, I just did it again. Restarting the Mac is the only way for me to get it back to work. Also when I quit the
wasp start command and restart it manually it does result in the same error. Does indeed sound like some weird background process, but then again restarting the Database itself works fine without issue and the pg-boss error is about not being able to connect. :/
Just tried to reproduce this error with a fresh project but when I did create a new wasp project with wasp new and selected Saas it worked fine. In this project I can restart wasp as much as I want and it does compile successully.
When I then stop the stop the new test db and app and try to start my real app I get the same error.Wohooo @Gwaggli, you just became a Waspeteer level 4!
Neither upgrading the wasp cli nor cleaning the
.wasp output directory helped. I created my App back in April I don't know if that helps. I might try tomorrow to set up a new App, and copy all my code over to the new app directory and see if that helps in any way.
Edit: Just tried to create a new wasp project with wasp new and selected basic and copied the content of my wasp file and the source code over and run into the same problem.
If I mess up the pg-boss by restarting my real application I can't run the freshly created app anymore either. Also restarting rancher desktop does not resolve the issue.Thanks for all this info -> that sounds like something is certainly being left behind.
Let me try to replicate this on my machine.
Ok, so I just tried to replicate it with on of our example apps that demonstrate jobs, and I couldn't replicate the problem.
It is a pretty simple app, so what might be great is if you try to run it and see if it works for you.
Locally clone this repo: https://github.com/wasp-lang/wasp .
Then, checkout the
release branch and go into examples/cronjobs-analytics-waspleau directory. This is an example app I mentioned.
Do wasp db start and leave it running, then in another terminal window do wasp db migrate-dev and once that is done do wasp start.
You might need to wait 10 to 20 seconds for it to fetch initial data (via jobs), but once that works, it should show some github repo stats on the screen (like num of gh stars and similar).
Now, I tried killing wasp start manually and starting it again, I tried modifying main.wasp, I tried modifying code on the client, and also code on the server, and nothing caused any issues. I am interesting how this will go for you. I was using the latest version of Wasp, 0.11.8.
Additional to this, it would be good if you could let me know some extra info about your machine: OS you are running, node version, anything else you think might be significant.
Finally, if you are not able to replicate the error with our example, what remains is you taking your app and stripping out stuff from it until you get to minimal working thing that causes error -> then you can share that with us and we can see if it also happens on our sides, under the same conditions (same OS, node version, ...).Hi Martinsos,
Thank you again for the effort! Really much appreciated 🙂
I tried it the way you described it. Again first run worked perfectly fine and it showed the stats. But after restarting the same error occurred but with a more comprehensive error trace. I piped it into a file and uploaded it here: https://filetransfer.io/data-package/Y2ncLq3a#link
I am working on a Macbook Pro with an M2 Max chip, 64 GB memory, and Sonoma 14.2.1
Using node 18.2.0 as suggested by wasp with npm version 8.19.2 and Posgtresql@14 via homebrew. (just also tried postgres@16 now and ran into the same issue)
I hope this helps.
Edit: As soon as I remove the jobs declaration from the wasp file, it recompiles and starts working again.
FileTransfer.io
Download Data package from December 25th.
Size of the data package: 104.1 kB. Free transfer of up to 6 GB of photos, videos and documents. Send large files via email or a link to share. No registration, no ads, just simple file sharing!
Thanks, this helps a lot!
For the record, log is quite longer, but it doesn't seem to say anything new, it seems it is the same error -> pg-boss can't connect to the database.
So yeah, it seems like it can connect to the database, it is just pg-boss that is causing issues?
All that info about node and postgres version helps quite a bit, thanks for that.
I just tried replicating it again, and I also tried varying postgres version from 14 to 16, but no luck, doesn't seem to be the cause.
We also have one other user seemingly having the same issue as you, so there is certainly something to it, we just need to figure out how to replicate it on our side.
I am on Linux, and both you and that other user are Mac with Mx chips, so we will have a team member with Mac try to replicate it tomorrow and let's see where that gets us.
In the meantime, one thing that might be useful is log from your
wasp db start command -> what it logs when it starts, but also any logs that might appear on failed connection by pg-boss.Hey @Gwaggli could you please try running the following minimal example app I put together? 🙂
It has two things:
- it tries to run some PgBoss job
- it tries just to connect to a Postgres DB
If you could please download and unzip it. Then
npm install then check out the README.md for a command to run the database with Docker.
After that please run the two tests by running:
- first npm start
- then npm run second-test
Please report back when you have time 🙂Hey @miho
Thanks a lot! I just did as you described but weirdly enough i get the mentioned error from the very first start already.
The output from the db start command is attached as a file bc its too long:
https://filetransfer.io/data-package/DGfy2QsL#link
Weird is the second last line?
Log from the
npm run start command:
FileTransfer.io
Download Data package from January 1st.
Size of the data package: 3.29 kB. Free transfer of up to 6 GB of photos, videos and documents. Send large files via email or a link to share. No registration, no ads, just simple file sharing!
Also i found this thread on github: https://github.com/brianc/node-postgres/issues/2895
GitHub
Node.js LTS v18.12.0 breaks · Issue #2895 · brianc/node-postgres
Hello, I seem to have connection issues when I tried the latest Node.js LTS. I downgraded back to v16.18.0 and everything started working again. Is there anything I can provide to assist?
Logs from
wasp db start are looking fine -> that "shutdown" part is a bit weird to see, but if I remember correctly, we normally have that in the output, so that is probably just fine.
I will leave the rest to @miho !@Gwaggli have you tried running the second command
npm run second-test? 🙂 Could you also share the output of that, thank you!@miho Like this?
Just noticed, that the error message looks the same as when I do not start the db at all for both runs.
This is the DB Log. I kind of think it could have something to do with the ipV6 issue I linked above. As it always states
connection refused for ::1:5432 Is there a way, we can tell pg-boss to use ipV4 connection to try it?
Yeah, it is as if it can't connect to the database. WHat is weird though, is that all works if you turn of pg-boss, right?
ipV4 vs V6 -> interesting idea, but I see from db logs that is listening to both V4 and V6 hm.
I will let @miho lead the main course of inquiry, but as a side question: do you have any other Postgres processes running? Maybe the Postgres server started on startup?
WHat is weird though, is that all works if you turn of pg-boss, right?The second test disproves that, since the second test is just connecting with
pg to the database.
@Gwaggli one thing to note in the DB output it says:
listening on IPv4 address "0.0.0.0" port 5432and
listening on IPv6 address "::" port 5432which would mean that Postgres is listening on both IPv6 and IPv4 Maybe try changing the
localhost to 127.0.0.1 in the test app I sent you? That's one of the things we can also try doing, that forces the app to use IPv4 connection to the DB@Gwaggli I asked if you have a native Postgres running on your machine because I know on Mac if you have native Postgres running and then also run Postgres via Docker (like
wasp start db does) then you get into some weird situation where that port 5432 gets taken by native postgres and it looks like wasp start db is also using that port, but is not, it is really just some kind of virtual port or what is it.
So I am interested really if something else took over that port and therefore our wasp start db doesn't really get to listen to it, although it thinks it does.
Besides that, another thing that might be interesting checking is what is running on port 5432. Quick googling tells me lsof -i tcp:5432 might do the job? Not sure though, maybe there is a better way. You could try checking what is running on port 5432 without wasp start db running, and then also with it running.@miho I replaced the
localhost with 127.0.0.1 and both runs seemed to work in your test setup.
@martinsos I also uninstalled postgres with brew and tried again, this did however make no difference. Still the same error.
Is there a way i can set the local db connection string to 127.0.0.1 instead of localhost?
Alright, got it!
When i set the DATABASE_URL env variable, i can not start the db. But when i only set it after starting the db but before starting the app it works and the app builds successfully! Is there a way we can change localhost to 127.0.0.1 without this workaround?
Thanks a lot for the patience and help! Very much appreciated! ❤️This definitely indicates a problem with IPv6 vs. IPv4 connectivity issues hmmm. I think it should just work with
localhost with the usual setup. We'll try to figure it out and maybe ping you with some additional tests if you are okay helping us with that?
One thing you can do now for your local development is to run the database with a docker run command instead of using our wasp start db command. Then, you are free to set your DATABASE_URL to the one you need with 127.0.0.1 and you can develop you like, it's not a big deal until we figure out the real issue with the IPv6 addresses 🙂
An example docker run command you can use:
Thanks a lot! I will be definitely available to further help you. And thanks for the docker command, I might try this in the meantime 🙂
I wonder why this error started happening recently, and why was it manifesting with pg-boss and not normal db connection?
@miho what do you think, should we change the local db connection string from
localhost to 127.0.0.1?
What should we do in the future to avoi dthis problem happening for other people?@martinsos the second test indicates that the same error happens for normal db connection
As for the question, I'm not sure. Changing the connection string from
localhost to 127.0.0.1 makes us less future-proof since localhost resolves to what ever it needs to e.g. 127.0.0.1 or maybe some other setup in the /etc/hosts. We should further investigate this and see if Node.js on MacOS doesn't work properly and what is the recommdeded Node.js fix. If possible I'd avoid modifying Wasp to accommodate Node.js's quirks that can be worked around (possibly, but I can't know for sure).
Oh ok makes sense, wasn't aware of this!
@miho can you create a GH issue for this please?
Here's an issue where we can track it: https://github.com/wasp-lang/wasp/issues/1621
GitHub
Connection to the database via IPv6 fails · Issue #1621 · wasp-lang...
Some users reported failures with pg-boss's connection to the database. On a closer look, it seems that it's a general database connection issue due to using IPv6 to connect. Check this out...