cron job every minute
Hey, I accidentally deployed a job with a cron schedule * * * * * (every minute). The job takes longer than a minute to complete, so multiple overlapping executions built up over time. I have since updated the schedule to 0 4 * * *, but I still see the job executing repeatedly as if it's still catching up or stuck in a loop. Is there some queue backlog or pending jobs that PgBoss / Wasp keeps trying to process even after changing the schedule? How can I fully reset or clear these queued jobs so only the new schedule applies?
10 Replies
Hi @Sven. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Yes, if you had a Wasp job scheduled with a cron of
* * * * * (every minute), and the job executions took longer than a minute, PgBoss would queue up multiple overlapping executions. When you update the schedule in your .wasp file, it only affects future scheduling—any jobs already queued in the PgBoss tables will remain and continue to execute until processed or expired.
To fully reset or clear these queued jobs so only the new schedule applies, you need to manually remove the pending jobs from the PgBoss tables in your PostgreSQL database. Specifically, you should look at the job and schedule tables in the pgboss schema. If you changed the job name or removed the schedule, old scheduled jobs may become stale and continue to execute without a handler, so it's important to clean up these tables.
From the Wasp documentation:
If you change a name that had apg-boss considerations So, to clear the backlog: 1. Connect to your PostgreSQL database. 2. Inspect thescheduleassociated with it, pg-boss will continue scheduling those jobs but they will have no handlers associated, and will thus become stale and expire. To resolve this, you can remove the applicable row from thescheduletable in thepgbossschema of your database. If you remove aschedulefrom a job, you will need to do the above as well.
pgboss.job and pgboss.schedule tables.
3. Delete rows related to your job from these tables to clear out pending and scheduled executions.
This will ensure only the new schedule is active and no old jobs are left running. Be careful when deleting rows—make sure you only remove jobs related to the affected job name.
If you need more details on the PgBoss schema or commands, refer to the pg-boss documentation.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Sven, 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?how do i do this:
@kapa.ai
Let me check the knowledge base for you again. One moment! :books:
----------------------
To connect to your PostgreSQL database and inspect the
pgboss.job and pgboss.schedule tables, you can use any standard PostgreSQL client tool, such as DBeaver, pgAdmin, or the psql command-line tool.
If you are using Wasp's managed dev database (started with wasp start db), Wasp prints the connection string (including username and password) at the top of the output. You can use this connection string to connect with external tools like DBeaver or pgAdmin. The same applies if you are running your own Postgres instance—the credentials in your DATABASE_URL are what you use to connect with these tools see Discord discussion.
Once connected, you can inspect the tables by running SQL queries such as:
This will show you the current jobs and schedules managed by PgBoss in your database.
If you need to find the connection string, look at the output of wasp start db (for dev) or check your .env.server file for the DATABASE_URL variable (for custom setups) see Wasp docs.
Summary of steps:
1. Get your database connection string from wasp start db output or .env.server.
2. Use a tool like DBeaver, pgAdmin, or psql to connect.
3. Run the SQL queries above to inspect the pgboss tables.
If you need to clear jobs, you can use SQL DELETE statements, but be careful to only remove the relevant rows.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Sven, 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?no i need to cancel all before scheduled jobs... how?
connect to your prod db on fly using this guide -- > https://github.com/wasp-lang/learning-materials?tab=readme-ov-file#running-wasp-db-studio-on-production-db
then remove the queued jobs from the pgboss schema.
Omay
Tha ks
what happesn when i proxy my db and run my app locally?
i see the actual data in db but can it change this too then? the production db?
I don't understand the question, can you specify a bit pls?
Well i proxied my database with fly, then normallt i do ‘wasp db studio’ to see what data etc there is in my prod database. But last time i did wasp start. Which caused my local webapp to run on my prod database.
Is this a bad practice? Kan jt also alter the database in any bad way?
Yep, bad practice 😅 If you connect your local webapp to your prod database, any small error you might make in development as part of the normal process (e.g. removing a column without realizing), will be done on your production data, so you might suffer data loss. If you proxy your prod database you should be quite careful and, if possible, only do read-only operations.
Thought so