Inconsistent behavior when background job is based on a variable's method call

[odinserj]

Based on a forums discussion, please see https://discuss.hangfire.io/t/jobs-in-enqueue-state-most-never-run-sql-only/2367/7. Consider the following background job creating logic.

IJob job = new MyJob();
BackgroundJob.Enqueue(() => job.Execute());

This is a special case, that I strongly discourage to use in your projects (you should prefer using BackgroundJob.Enqueue<MyJob>(x => x.Execute()) instead), because the state of a variable isn't serialized anyway, and you are creating unnecessary instance. However sometimes it is useful, especially when you're migrating from another background processing system.

When using this semantics, the resulting background job will be based on an actual type of the job variable. If a base class is used as a job variable's declared type, then all is fine. But when an interface is used as a declared type, like IJob in our case, then the resulting background job method will be based on IJob.Execute method.

The latter will happen and will be only visible for filters that are acting on an initial state change. Other state changes will use the correct MyJob.Execute method. So the current behavior is inconsistent, and break expectations, for example, when using the QueueAttribute:

public class MyJob : IJob 
{ 
    [Queue("critical")]
    public void Execute() { /* ... */ }
}

In this case, background job will be placed on the default queue first. But if we re-queue it from the dashboard, it will be placed to the critical queue.

[nhaberl]

Is this fixed? I have the problem when defining the Queue attribute in the Interface method the job is always in enqueued state ... and stays there (SQL 2012) and Hangfire 1.6
So what is the recommended way of handling this? Adding base Job class? And where should we define the attributes, abstraction or implementation ?