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

Obliterate not working properly #2016

Closed
Theo-Le-Donne opened this issue Apr 22, 2021 · 8 comments
Closed

Obliterate not working properly #2016

Theo-Le-Donne opened this issue Apr 22, 2021 · 8 comments
Labels

Comments

@Theo-Le-Donne
Copy link

Theo-Le-Donne commented Apr 22, 2021

Description

I try to implement the obliterate method but i get a strange behavior.

Basically i ave a batch of jobs that are used to periodically execute requests, and i want a "reset" method, that removes all jobs and recreate them. I was doing this "manually" using some pause(), empty(), moveToCompleted(), but obliterate seems to be the perfect fit.

Problem is that obliterate seems to miss failed and delayed jobs.

Here are the stats (bull-repl) after 4 "resets".

Capture d’écran 2021-04-22 à 11 07 35

Capture d’écran 2021-04-22 à 11 07 51

Capture d’écran 2021-04-22 à 11 08 02

Capture d’écran 2021-04-22 à 11 25 13

As you can see, each "reset" adds ~1400 delayed jobs. But the delayed count increase at each "reset", and failed jobs are not removed.

Anyone seen this behavior ?

Simplified code

const initQueue:  QueueInit = (): Queue<TQueuePayload> => {
  const queue: Queue<TQueuePayload> = new Bull(CACHE_QUEUE_NAME, {
      redis: QUEUE_REDIS_URL,
  });

  /**
   * @description Cleans the queue from running and waiting jobs, and inits all the cache search jobs
   * @returns {Promise<void>}
   */
  queue.reset = async (): Promise<void> => {
      await queue.obliterate({ force: true });
      await queue.resume();

      // In a for loop
      array.push(queue.add(payload, 
        {attempts: 1,
          lifo: true,
          removeOnComplete: true,
          removeOnFail: true,
          timeout: 30000, 
          delay: someDelay
       })
      )

      await Promise.all(array);
  }

return queue;
}

// In a script later
const queue = initQueue();
await queue.reset()

Bull version

3.22.1

@manast
Copy link
Member

manast commented Apr 22, 2021

thanks for the report. I cannot see anything that would cause such a behaviour. Would you mind to write a test case that demonstrates that this actually happens? for example, this is one test for the obliterate function:

  it('should obliterate a queue with jobs in different statuses', async () => {
    await queue.add({ foo: 'bar' });
    await queue.add({ foo: 'bar2' });
    await queue.add({ foo: 'bar3' }, { delay: 5000 });
    const job = await queue.add({ qux: 'baz' });

    let first = true;
    queue.process(async () => {
      if (first) {
        first = false;
        throw new Error('failed first');
      }
      return delay(250);
    });

    await job.finished();

    await queue.obliterate();
    const client = await queue.client;
    const keys = await client.keys(`bull:${queue.name}*`);
    expect(keys.length).to.be.eql(0);
  });

@Theo-Le-Donne
Copy link
Author

Thanks for the reply !
Here is a failing test running on a on higher number of jobs:

  it('should obliterate a queue with high number of jobs in different statuses', async () => {
    await queue.add({ foo: 'bar' });
    await queue.add({ foo: 'bar2' });
    const arr = [];
    for (let i = 0; i < 2000; i++) {
      arr.push(queue.add({ foo: `barLoop${i}` }, { delay: 10000 }));
    }
    await Promise.all(arr);
    await queue.add({ foo: 'bar3' }, { delay: 5000 });
    const job = await queue.add({ qux: 'baz' });

    let first = true;
    queue.process(async () => {
      if (first) {
        first = false;
        throw new Error('failed first');
      }
      return delay(250);
    });

    await job.finished();

    await queue.obliterate();
    const client = await queue.client;
    const keys = await client.keys(`bull:${queue.name}*`);
    expect(keys.length).to.be.eql(0);
  });

Capture d’écran 2021-04-22 à 14 34 53

@rimiti
Copy link

rimiti commented Apr 22, 2021

We've the same issue. This function doesn't work properly when you queues have a lot of jobs.

@Theo-Le-Donne
Copy link
Author

Also fyi i added a PR on DefinitelyTyped to add type definition for obliterate()

DefinitelyTyped/DefinitelyTyped#52510

@manast
Copy link
Member

manast commented Apr 22, 2021

I found the issue, I am working on a fix

@Theo-Le-Donne
Copy link
Author

Great ! Found it too i think, maxCount at 1000

@Theo-Le-Donne
Copy link
Author

I found the issue, I am working on a fix

Hey, just wanted to know, should we expect a fix soon or do i focus on a workaround for now ? Thanks

@manast manast closed this as completed in 7a923b4 Apr 23, 2021
github-actions bot pushed a commit that referenced this issue Apr 23, 2021
## [3.22.2](v3.22.1...v3.22.2) (2021-04-23)

### Bug Fixes

* **obliterate:** obliterate many jobs fixes [#2016](#2016) ([7a923b4](7a923b4))
@manast
Copy link
Member

manast commented Apr 23, 2021

🎉 This issue has been resolved in version 3.22.2 🎉

The release is available on:

Your semantic-release bot 📦🚀

papandreou added a commit to papandreou/bull that referenced this issue Apr 27, 2021
* develop: (39 commits)
  chore(release): 3.22.3 [skip ci]
  fix(delayed): re-schedule updateDelay in case of error fixes OptimalBits#2015
  chore(release): 3.22.2 [skip ci]
  chore: fix github token
  chore: correct release branch
  test: increase timeout in test
  chore: add semantic release scripts
  fix(obliterate): obliterate many jobs fixes OptimalBits#2016
  3.22.1
  chore: upgrade dependencies
  chore: update CHANGELOG
  fix(obliterate): remove repeatable jobs fixes OptimalBits#2012
  docs: fix typo
  docs: update README.md
  docs: updated README.md
  Update README.md
  3.22.0
  docs: update CHANGELOG
  feat: do not rely on comma to encode jobid in progress fixes OptimalBits#2003 (OptimalBits#2004)
  3.21.1
  ...
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

3 participants