stalledInterval not working properly

BullMQ Version: 1.9.0

Trying to change the stalledInterval on a QueueScheduler does not seem to work properly.

My demo setup is this:

scheduler.js

"use strict";
const QueueScheduler = require("bullmq").QueueScheduler;
new QueueScheduler("testQ", {
    stalledInterval: 10000
});

worker.js

"use strict";
const Worker = require("bullmq").Worker;
new Worker("testQ", async (job) => {
    console.log(`Beginning Stalling: ${job.name} (${job.id})`);
    const a = new Date();
    while (new Date() - a < 40000) {} // Stall for 40 seconds
});

task-adder.js

"use strict";
const Queue = require("bullmq").Queue;
const queue = new Queue("testQ");
async function addTasks() {
    await queue.add(`testJob`, {
        attempts: 3,
        backoff: {
            type: "fixed",
            delay: 0
        }
    });
    queue.disconnect();
}
addTasks();

I start up 1 scheduler, then 1 worker and then I run task-adder once to kick the entire test off.

Attempting to set stalledInterval to 0 causes the following error message:

(node:18963) UnhandledPromiseRejectionWarning: ReplyError: ERR Error running script (call to f_890be59efdd64a4df5f5121df9680b166a884036): @user_script:28: ERR invalid expire time in set
    at parseError (PROJECT/node_modules/redis-parser/lib/parser.js:179:12)
    at parseType (PROJECT/node_modules/redis-parser/lib/parser.js:302:14)
(node:18963) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:18963) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

According to what I read in the documentation, 0 should turn the stalling check off, is that correct?

Futhermore, when I set stalledInterval to 10000, it should mark a job as stalled after 10 seconds, right? This does not happen for me and the 30 second default timeout is used instead.

The worker also stops processing when it recovers from the artificial stalling and finishes processing the task, erroring due to a missing lock. There are definitely more jobs on the queue for it to process.

[Wolvan]

Because I have jobs that have the potential to stall. I guess I should be using a sandbox’d script instead?

[Wolvan]

I see. I’ll take that suggestion to heart, then. Thank you!