Delayed jobs

[janwehner]

Hi,

I was playing around with the package and it did work really well until I tried to dispatch a delayed job with the ->delay method from Laravel because then the job was not processed at all.

I was investigating the problem a little bit and it does look like the package does not support delayed jobs at all. Since the package is only overwriting the push method from Laravel's RedisQueue class but not the later method, delayed jobs do get pushed in the normal delayed queue queues:{NAME}:delayed but not balanced-queue:queues:{NAME}:delayed. It also looks like the part where Laravel is moving delayed jobs back into the normal queue is not implemented at all for balanced queues, since the packages overwrites the RedisQueue::pop method, which is calling migrate in Laravel's implemenation which is doing the moving.

Do you plan on supporting delayed jobs?

[janwehner]

It seems like the missing migrate part in the package does also break the release method which can be used inside jobs to release the job back later in the queue. Since the package is moving the job into a balanced delayed queue with the releasePartitionJob but never moving the job back into the normal balanced queue.

[YanGusik]

Hi @janwehner,

Sorry for the late reply - the GitHub notification didn't reach me.

You're absolutely right. later() is not overridden, and migrate is missing from pop(). The release($delay) case is half-done -- it writes to the correct balanced delayed key, but since migrate is never called, those jobs are never picked up.

I'm planning to fix this over the weekend. Thanks for the detailed investigation!

[YanGusik]

Thinking about the fix:

later() is straightforward - just resolve the partition and push to the correct balanced-queue:queues:{name}:{partition}:delayed ZSET.

The trickier part is migrate. Since each partition has its own delayed ZSET, there are two approaches:

• Migrate all partitions on every pop() - honest but potentially expensive with many partitions (not recommend for production)
• Migrate only the selected partition - cheaper, but if a partition isn't visited for a while (e.g. all slots are busy), its delayed jobs might be delayed longer than expected

Honestly, I'm not sure which is preferable. Might expose it as a config option and let users decide based on their use case. Open to thoughts if you have an opinion!

[janwehner]

I was also thinking of migrating only the selected partition. My idea was to add the partition key into the SET when an job is pushed in the balanced-queue:queues:{name}:{partition}:delayed queue. I think this would ensure the queue is visited. But I'm not sure if it will make it less efficient or more expensive. In worst case it will visit a queue often without having to do anything because it has nothing to migrate yet, the normal partition is empty and it can select the next partition.

[YanGusik]

Fixed in v1.2.0 🎉

• Added later() override — delayed jobs now go to the correct partitioned delayed key
• Added migrate step in pop() — ready delayed jobs are moved to the partition queue before each pop
• release($delay) now works correctly end-to-end

Thanks again for the detailed report!