Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • B bull
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 175
    • Issues 175
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 9
    • Merge requests 9
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • OptimalBits
  • bull
  • Issues
  • #830
Closed
Open
Issue created Jan 04, 2018 by Administrator@rootContributor

Named Process Sent to Wrong Processor

Created by: PrestonR

Description

Upon app boot-up, the following named processes, process, on the correct processors (i.e. they are routed to the correct process based on process name). However, because they are repeatable, all subsequent attempts are attempting to process both jobs on the last auditor path defined in the sequence

Test code to reproduce

const queue = {
   auditor: new Queue('auditor', opts)
}

queue.auditor.add( 'auditor1', { repeat: { cron: '*/2 * * * *' } } );
queue.auditor.add( 'auditor2', { repeat: { cron: '* * * * *' } } );

queue.auditor.process( 'auditor1', 1, AUDITOR_PATH_1 );
queue.auditor.process( 'auditor2', 1, AUDITOR_PATH_2 );

AUDITOR_PATH_1 ends up getting ignored, and both auditor1 and auditor2 process on AUDITOR_PATH_2. Needless to say, AUDITOR_PATH_2 fails for auditor1 because neither processsor's code supports the other.

Are you able to confirm and reproduce this? The only work around I can think of is to just put each of them on separate queues.

Bull version

3.3.7

Additional information

Node 8 LTS

Assignee
Assign to
Time tracking