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

feature suggestion: accept-jobs-only mode #2157

Closed
EricWVGG opened this issue Sep 7, 2021 · 3 comments
Closed

feature suggestion: accept-jobs-only mode #2157

EricWVGG opened this issue Sep 7, 2021 · 3 comments
Labels

Comments

@EricWVGG
Copy link

EricWVGG commented Sep 7, 2021

I am using Bull in conjunction with NestJS for an API server. (It is working beautifully, I am very impressed with this project and its integration!)

I am, however, running into a problem with CLI commands. The CLI boots up a new instance of the server, runs a few seed commands (including the insertion of some Bull jobs), and then shuts down. The problem is, the Bull jobs start running immediately in the CLI runtime, and crash out when required services (notably the database) are turned off.

pause() and resume() don't work in this context; when I run queue.pause() upon CLI startup, the pause state is stored in Redis, so my API server pauses jobs — not ideal — and when I queue.resume() upon CLI shutdown, the same crashing thing happens.

I feel like the real solution here is to have a flag separate from isPaused perhaps called isSuspended; the "suspended" state would function the same as isPaused, but be defined in the runtime memory instead of in Redis.

Does this make any sense? Or is there already a way to handle this that I'm overlooking?

@EricWVGG
Copy link
Author

EricWVGG commented Sep 7, 2021

(note that I have found one way around this, which is to add a delay of one minute to newly inserted jobs when the CLI environment is detected; I think this is kind of hacky, and anyway if the CLI command takes more than a minute, or a job is inserted on the live server while the CLI instance is running, I'm back to square one…)

@cincodenada
Copy link
Contributor

cincodenada commented Nov 5, 2021

I'm not familiar with NestJS, but this seems like more of a feature suggestion for the NestJS integration if anything.

In usage of Bull itself, a queue instance will only process jobs if it has a processor attached to it, so queues are basically in accept-jobs-only mode by default. See this example, where I add a job to the queue, but it doesn't start processing until I call queue.process():

const Queue = require('bull')
const delay = require('delay')

;(async () => {
  const processor = function(job) {
    console.log(`Processing job ${job.id}`)
  }

  console.log('Starting up')
  const queue = new Queue('example')
  console.log('Adding job')
  queue.add({})

  await delay(2000)
  console.log('Adding processor')
  queue.process(processor)
})()

I don't know if something similar is possible in the NestJS integration, but it might be something to look into!

@stale
Copy link

stale bot commented Jan 4, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix label Jan 4, 2022
@stale stale bot closed this as completed Jan 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants