Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

All repeatable jobs become paused on first run? #2705

Closed
Linksku opened this issue Feb 13, 2024 · 2 comments
Closed

All repeatable jobs become paused on first run? #2705

Linksku opened this issue Feb 13, 2024 · 2 comments

Comments

@Linksku
Copy link

Linksku commented Feb 13, 2024

Description

I've been using Bull to run repeatable jobs for years. However, recently I've noticed jobs occasionally stop running. Even after restarting the server and re-adding all the Bull jobs, the job handlers don't run. Rebooting the machine fixes it, I'd assume flushing Redis fixes it too, but I haven't been able to try it.

When the server starts, I run queue.add. Using Bull Dashboard, I could see that the job was scheduled successfully. However, when it's supposed to run, it moves to the "paused" state without calling the process callback. Then, Bull never attempts to run the job again until the server restarts. On my dev machine, the server's restarting every time I save a file, so I end up with thousands of paused jobs.

Without digging into the Bull code, my hypothesis is that this starts happening after I restart the server. Bull assumes the old server instance is still available, so it attempts to run the job on the old server instance. If this is the case, how can I get Bull to run it on the new server instance instead? Am I supposed to run some cleanup function to tell Bull that the server instance will be no longer available?

I saw on another thread (#1739) that they fixed a similar issue by removing repeatable jobs before adding them. However, with multiple web servers sharing a Redis server, it'll remove and add jobs every time a server restarts.

Minimal, Working Test code to reproduce the issue.

(An easy to reproduce test case will dramatically decrease the resolution time.)

  queue.process(
    name,
    () => {
      console.log('ran');
    },
  );

  await queue.add(name, null, {
    repeat: { every: 60 * 1000 },
    timeout: 60 * 1000 ,
    removeOnComplete: true,
    removeOnFail: true,
  });

Bull version

4.11.5

@manast
Copy link
Member

manast commented Feb 14, 2024

I do not think this is a Bull issue, the queue going to pause status can only happen if you manually paused the queue, either via some frontend or using the API.

@Linksku
Copy link
Author

Linksku commented Feb 14, 2024

You're right, pause() is called occasionally, I thought recreating the queue meant I didn't need to unpause it.

@Linksku Linksku closed this as completed Feb 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants