You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have recently implemented Bull in our product and this is working dandy in development.
However, when deploying to production I'm seeing a weird thing happen. The process is firing immediately, despite only being defined as a repeat: { cron: .. } job.
This ends up in the deploy process terminating, with the folllwing log entry
2023-03-14T10:39:47+01:00 Nothing listening on 0.0.0.0:8080 yet. If the deployment fails after this message, please update your configuration and redeploy.
2023-03-14T10:39:47+01:00 [PROD] Using REDACTED email transport
2023-03-14T10:39:49+01:00 Current environment is: production
2023-03-14T10:39:49+01:00 Introdus backend listening on port REDACTED
2023-03-14T10:39:49+01:00 Connected to redis
2023-03-14T10:39:49+01:00 Mar 14 09:39:48 app[4682] INFO: ./d/app: Listening on REDACTED on production
2023-03-14T10:39:51+01:00 at process.processImmediate (node:internal/timers:442:9)
2023-03-14T10:39:51+01:00 at runNextTicks (node:internal/process/task_queues:60:5)
2023-03-14T10:39:51+01:00 ^
2023-03-14T10:39:51+01:00 at updateDBAndSendMessageOthers (/home/bas/app_cfe13b28-05ef-4b24-9077-1dcd2ed7b1ea/dist/src/common/jobs/processes/sendMessage.process.js:37:15)
2023-03-14T10:39:51+01:00 Error: JOB.USER_NOT_FOUND
2023-03-14T10:39:51+01:00 /home/bas/app_cfe13b28-05ef-4b24-9077-1dcd2ed7b1ea/dist/src/common/jobs/processes/sendMessage.process.js:37
2023-03-14T10:39:51+01:00 Node.js v18.11.0
2023-03-14T10:39:51+01:00 throw new Error('JOB.USER_NOT_FOUND');
I don't even think an error in this manner should be cancelling the build steps, but its weirder yet, because it shouldn't be running at this point. As you'll see below the queues are only being added as repeatable jobs.
Minimal, Working Test code to reproduce the issue.
(An easy to reproduce test case will dramatically decrease the resolution time.)
Currently this setup is part of a larger monolithic application. The relevant codebits are included below:
The method runNetworkUnreadsJob is there to run on-demand jobs, but isn't currently exported or in use anywhere.
And a process:
import { Job } from 'bull';
import organizationService from '../../../organization/organization.service';
import { JobsService } from '../jobs.service';
import { NetworkService } from '../../../network/network.service';
export const networkUnreadsProcess = async (job?: Job) => {
try {
await getNetworkUnreads(job);
} catch (err) {
console.log(err);
}
};
async function getNetworkUnreads(job?: Job) {
// some heavy lifting ...
}
Bull version
4.10.2
Additional information
I'm using Typescript. I previously had an issue with bull-board but that has now been resolved.
I don't understand this irregular behaviour and why it is attempting to run the code on deploy.
The only place the JOB.USER_NOT_FOUND error is used is from within sendMessagesQueue.
The hosting provider (Clever Cloud) does provide some cron tools, but it seems that it's not possible for me to execute just the bull processes/queues in an isolated environment, as it needs context from the rest of the application.
Am I missing an implication of sorts? That somehow the jobs will run right away but also on a repeatable schedule? I do not believe that is the case, but please let me know if I am wrong.
The text was updated successfully, but these errors were encountered:
aarhusgregersen
changed the title
Cron-based processes running immediately on deploy (process.processImmediate (node:internal/timers))
Cron-only queues running immediately on deploy (process.processImmediate (node:internal/timers))
Mar 14, 2023
The code you posted is way too complex for me to run, however, you must know that if there are old repeatable jobs already added from a previous run the will probably execute directly if it has been enough delay between the last time they were processed and the new workers came up online.
Yes I understand the example is complex, I'll try to see if I can replicate this in a separate install.
There are no old repeatable jobs having around. I am currently trying to replace this with bullMQ to see if this could be an issue with our hosting provider. Alternatively I believe it could be a redis connection issue.
I'll report back with findings, for anyone experiencing similar issue(s).
This could have been either a bull or a redis connection issue.
After migrating to bullMQ and set it up according to the docs I had no deploy issues, and bull-board is correctly displaying the jobs as running as scheduled jobs.
The way that it is now showing up in bull-board as a "Scheduled" job, instead of a "Waiting" job, leads me to think that I had misconfigured bull repeatable.
Description
I have recently implemented Bull in our product and this is working dandy in development.
However, when deploying to production I'm seeing a weird thing happen. The process is firing immediately, despite only being defined as a
repeat: { cron: .. }
job.This ends up in the deploy process terminating, with the folllwing log entry
I don't even think an error in this manner should be cancelling the build steps, but its weirder yet, because it shouldn't be running at this point. As you'll see below the queues are only being added as repeatable jobs.
Minimal, Working Test code to reproduce the issue.
(An easy to reproduce test case will dramatically decrease the resolution time.)
Currently this setup is part of a larger monolithic application. The relevant codebits are included below:
jobrunner.ts
app.ts
All of our queues and processes are formatted following a similar pattern, here's a sample queue:
The method
runNetworkUnreadsJob
is there to run on-demand jobs, but isn't currently exported or in use anywhere.And a process:
Bull version
4.10.2
Additional information
I'm using Typescript. I previously had an issue with bull-board but that has now been resolved.
I don't understand this irregular behaviour and why it is attempting to run the code on deploy.
The only place the
JOB.USER_NOT_FOUND
error is used is from withinsendMessagesQueue
.The hosting provider (Clever Cloud) does provide some cron tools, but it seems that it's not possible for me to execute just the bull processes/queues in an isolated environment, as it needs context from the rest of the application.
Am I missing an implication of sorts? That somehow the jobs will run right away but also on a repeatable schedule? I do not believe that is the case, but please let me know if I am wrong.
The text was updated successfully, but these errors were encountered: