[Question] Support polling as alternative to blocking commands?

[CrazyWood007]

​​Context:​​
In environments where Redis blocking commands (e.g. BRPOP, BLMOVE) are restricted (e.g. proxy-limited infrastructure or serverless runtimes), BullMQ fails to process jobs. These restrictions maybe prevent many users from adopting BullMQ.

​​Problem:​​

• Blocking commands cause connection timeouts in serverless platforms (AWS Lambda, Cloudflare Workers)
• Infrastructure proxies (e.g. Twemproxy) often block BRPOP/BLMOVE
• No workaround exists in BullMQ to force non-blocking behavior

​​Proposal:​​
Introduce a pollInterval option for workers, replacing blocking commands with interval-based checks:

new Worker("my-queue", async job => { }, {
  settings: {
    worker: {
      pollInterval: 2000 // ms (disables BLPOP when set)
    }
  }
});

​​Expected Behavior:​​

• Worker checks for jobs every pollInterval ms using non-blocking LRANGE/ZRANGE commands
• Fallback to standard blocking mode when pollInterval is null/undefined
• Document limitations: higher latency/Redis load tradeoff

​​Use Cases:​​

1. Serverless deployments with connection timeout restrictions
2. Proxy-mediated Redis connections
3. Edge environments with incomplete Redis command support

[manast]

@CrazyWood007 thanks for the suggestion. Do you have a more concrete example where this feature would be necessary and how it would work in practice? For server less I am not sure how this would work for example, as I don't know how a lambda for instance would be triggered to process a job that is waiting in a queue? for these cases we have the bullmq-proxy though, that I think solves most issues but requires at least one node running the proxy: https://docs.bullmq.net