There appears to be a contradiction in the recurring job API where both ways of setting a queue are marked obsolete, leaving no clear non‑obsolete option.
RecurringJobOptions.QueueName is obsolete and advises using an explicit queue parameter instead:
|
[Obsolete("Please use non-obsolete AddOrUpdate with the explicit `queue` parameter instead. Will be removed in 2.0.0.")] |
|
[NotNull] |
|
public string QueueName |
The AddOrUpdate extension method that accepts an explicit queue parameter is also marked obsolete and points back to an overload that relies on RecurringJobOptions:
|
[Obsolete("Please use the AddOrUpdate<T>(string, Expression<Func<T, Task>>, string, RecurringJobOptions) extension method instead. Will be removed in 2.0.0.")] |
|
public static void AddOrUpdate<T>( |
As a result:
Setting the queue via RecurringJobOptions produces an obsoletion warning
Setting the queue via the queue parameter also produces an obsoletion warning
There is no non‑obsolete way to specify a recurring job queue
This overlaps with earlier reports where the queue is ignored or inconsistently applied:
RecurringJobManager does not use the provided queue name
#2544
RecurringJobManager.AddOrUpdate ignores queue option
#2314
Functionally, the queue can work, but only by relying on APIs marked for removal in 2.0.0.
Question:
Is this an oversight in the obsoletion annotations, or is there a supported, non‑obsolete API for configuring the queue on recurring jobs?
There appears to be a contradiction in the recurring job API where both ways of setting a queue are marked obsolete, leaving no clear non‑obsolete option.
RecurringJobOptions.QueueName is obsolete and advises using an explicit queue parameter instead:
Hangfire/src/Hangfire.Core/RecurringJobOptions.cs
Lines 48 to 50 in 333bd8e
The AddOrUpdate extension method that accepts an explicit queue parameter is also marked obsolete and points back to an overload that relies on RecurringJobOptions:
Hangfire/src/Hangfire.Core/RecurringJobManagerExtensions.cs
Lines 495 to 496 in 333bd8e
As a result:
Setting the queue via RecurringJobOptions produces an obsoletion warning
Setting the queue via the queue parameter also produces an obsoletion warning
There is no non‑obsolete way to specify a recurring job queue
This overlaps with earlier reports where the queue is ignored or inconsistently applied:
RecurringJobManager does not use the provided queue name
#2544
RecurringJobManager.AddOrUpdate ignores queue option
#2314
Functionally, the queue can work, but only by relying on APIs marked for removal in 2.0.0.
Question:
Is this an oversight in the obsoletion annotations, or is there a supported, non‑obsolete API for configuring the queue on recurring jobs?