Examining the source code: are job IDs expected to be numeric?

[twelve17]

I have been running into unexpected out-of-order processing of messages from the delayed queue.

I do not yet know if this is related, but, studying the scripts file, the moveToDelayedArgs function says:

Bake in the job id first 12 bits into the timestamp

I see that it does so via jobId & 0xfff. This seems to assume that the job Id is a numeric value. If the value has any non-numeric values that would fall into the first 12 bits, then the resulting value would be 0:

> "123" & 0xfff
123
> "12238382838233" & 0xfff
473
> "a-123456789" & 0xfff
0
> "some-job-128282" & 0xfff
0

In the reference doc, the jobId type is defined as jobId: number | string;, which to me implies that a string value, not necessarily entirely made up of numeric characters, is accepted.

Is it possible that the first twelve bits of a job Id not being numeric characters throw off ordering of execution in the delayed queue?

[manast]

The id used in the expression "jobId & 0xfff" is the actual job counter, probably should be renamed to job counter, as it is the case in the newer BullMQ codebase: https:/taskforcesh/bullmq/blob/master/src/commands/addDelayedJob-6.lua#L96
which by the way has better support for delayed jobs.

[twelve17]

Thanks for the context @manast