RecurringJobManager does not use the provided queue name

[dlumpp]

RecurringJobManager.AddOrUpdate does not use the Job.Queue from the job argument when creating the RecurringJobEntity. Instead, the obsolete RecurringJobOptions.QueueName is used.

I discovered this because the obsolete extension methods recommend using a RecurringJobOptions overload. However, if you do use one of those then you can only set the queue via the obsolete RecurringJobOptions.QueueName property. The string queue argument never makes it. You're stuck with an obsolete warning either way.

Hangfire.Core v1.8.21

[odinserj]

Unfortunately, the RecurringJobOptions.QueueName works only on the initial queueing, and doesn't work on retries, that's why it was deprecated. Since Hangfire 1.8.0, it's possible to specify the queue name directly for a job using the AddOrUpdate(string id, string queue, Expression methodCall) method overload, or use the Hangfire.DynamicJobs extension and passing QueueAttribute as a filter when creating a recurring job.

[dlumpp]

I think you're saying the current, correct approach is to use one of the extension methods that has a string queue parameter, like AddOrUpdate(string recurringJobId, string queue, Expression<Action> methodCall, Func<string> cronExpression), right?

However, if you use one of those methods, then the queue value never gets set on the recurring job. It ends up getting assigned to the Job.Queue property which is never read by the RecurringJobManager.

This seems like a bug unless I misunderstand something.

[odinserj]

I think you're saying the current, correct approach is to use one of the extension methods that has a string queue parameter, like AddOrUpdate(string recurringJobId, string queue, Expression methodCall, Func cronExpression), right?

Right, this is a correct approach for now.

However, if you use one of those methods, then the queue value never gets set on the recurring job. It ends up getting assigned to the Job.Queue property which is never read by the RecurringJobManager.

The queue is set in the Job.Queue (e.g. in the underlying job) and not in the recurring job itself. Despite the RecurringJobManager does not read the queue directly, the Job.Queue value is used when background job is created and enqueued.

Everything should work fine, but there were some discrepancies between displaying the actual queue in the Dashboard UI and the actual queue that was used for the background job. I have implemented some changes in Hangfire 1.9.0 to avoid such confusion, but I will appreciate if you could share some screenshots that cause the confusion to ensure everything will look fine at least since 1.9.0.

[dlumpp]

What I was missing is that the underlying job also gets serialized to the recurring job hash table.

I was confused when I queried this value and thought my recurring jobs would end up in the wrong queue:

select [Value]
from Hangfire.Hash
where [Key] = 'recurring-job:myrecurringjob'
and [Field] = 'Queue'

but you're saying it works fine because of this value:

select JSON_VALUE([Value], '$.q') as q
from Hangfire.Hash
where [Key] = 'recurring-job:myrecurringjob'
and [Field] = 'Job'

I think everything does work fine. Thanks for explaining.

[Ruhrpottler]

I had the same confusion. The reason is already explained above.
What maybe helps others:

If you want to check with the new logic, for which queue the job is running for, do not usedto.Queue - this may be wrong if you do not use the deprecated RecurringJobOptions parameter "QueueName". Use dto.Job.Queue instead to get the right answer.