Hangfire: Queue parameter is ignored when scheduling job with IBackgroundJobClient

[shatl]

Hi,
same job goes to different HF queues when enqueued using static method and IBackgroundJobClient

  // .NET Core controllerm _jobs injected in constructor 

        [HttpGet("{message}", Name = "Echo")]
        [Route("echo")]
        public string Echo(string message)
        {
            // goes to default queue
            /* IBackgroundJobClient*/ _jobs.Enqueue<ITestJob>(x => x.DoIt(message));
            // goes to correct queue
            BackgroundJob.Enqueue<ITestJob>(x => x.DoIt(message));
            return message;
        }

    public interface ITestJob
    {
        [Queue(Settings.HangfireTransmitQueueName)]
        void DoIt(string msg);
    }
    class TestJob : ITestJob
    {
        public void DoIt(string msg)
        {

        }
    }

[pieceofsummer]

Wow, looks like one of the bugs I've just fixed in #800 :)

The reason is, IBackgroundJobClient uses IJobFilterProvider service from IoC (which is GlobalJobFilters.Filters), while the static wrapper uses JobFilterProviders.Providers. The latter combines global job filters from the former one with filters coming from class/method attributes. Hence, IBackgroundJobClient just knows nothing about attributes on your method.

While waiting for the official update, you may try a quick fix – add the following line to ConfigureServices() right before AddHangfire():
```c#
services.AddSingleton(_ => JobFilterProviders.Providers); // <-- !!!

services.AddHangfire(config => {
...
});
```

[shatl]

Awesome!
Thanks @pieceofsummer

[shatl]

Guys, any ETA on release date for this?

[shatl]

any news so far?

[madannes]

I've just run across this same issue in v1.6.9 on .NET 4.6.2. In glancing at the commits in the pull request, it looks like you're only affecting the .NET Core code. Should a separate issue be created for .NET 4.6.2?

[pieceofsummer]

Yes, that was mostly the .NET Core issue.

I have really never used Hangfire on a classic .NET, so can't say for sure. But looking at Hangfire.AspNet package, I don't really see any code affecting the job filter providers.

So it might be just your code. Or maybe I'm looking at the wrong package :)

[burningice2866]

@pieceofsummer the Hangfire.AspNet package only contains some helper-classes to ensure proper shutdown on asp.net - personally i've never used any of it even though i run a dozen of sites using HangFire on Asp.Net.

As far as i understand all of HangFire runs on Classic .Net of the box and only has special behavior for .Net Core.

[burningice2866]

Personally i would prefer to see everything related to DI and Logging from the AspNetCore package be backported back to Core since neither Microsoft.Extensions.DependencyInjection or Microsoft.Extensions.Logging is restricted to be used only on .Net Core.

[shatl]

Any updates on this ?

[odinserj]

Closing this issue as #800 already merged.