Hangfire: Dashboard not able to trigger a recurring job

[lineker]

This is my setup.
2 different websites on IIS
Website A - has a running instance of Hangfire BackgroundJobServer
Website B - has the owin instance of Hangfire Dashboard.

Website A and Website B don't share any code (dll)

I'm trying to trigger a recurring job that was added by Website A from the dashboard running on Website B and it doesn't work.
It seems like Website B (Dashboard) is trying to run the job (when manually trigger) from its context and since it doesn't have references to the dll it fails to run. The error message I get is Could not load file or assembly ....

Is that a bug? Should the dashboard (website B) queue the job so it can be process by a worker on (Website A) ?

Thanks
Version : Hangfire 1.6.17

[lgoudriaan]

No this isn't a bug, see the answer of @pieceofsummer on #1002

[lineker]

I don't mind if it doesn't show up the job name or any metadata about the method. My problem is that if I trigger the job it doesn't get queue.

[pieceofsummer]

@lineker Hangfire requires method info available for all states (except Deleted) by design.

Even if you only want to trigger a scheduled job, Hangfire still needs to examine class/method metadata to determine target queue and job filters to execute before/after enqueuing.

[lineker]

So what you are telling me is that is impossible for one machine trigger a job that will run in another machine unless they share the same code base?

[dcorbett-fivebridgesllc]

They have to at least share the interface, and any interfaces/classes used in the method call, in that same interface.

[lineker]

I might be over simplifying things but shouldn't the dashboard only queue the job to be execute by an executor ? is that design flaw? why does it needs to know the interface of the job ?

[pieceofsummer]

To enqueue a job instance for a recurring job Hangfire needs to actually create a new job record and perform initial state transition to Enqueued state. Any state transition requires running all the relevant IElectStateFilters and IApplyStateFilters for it, and some of those are resolved from class/method attributes.

Triggering a recurring job is actually no different from enqueuing/scheduling a regular job, which you cannot do without knowing the method you're going to run, so this is a consistent behavior.

[pawil31]

For my point of view it is really a problem. I have similar setup:
Website with dashboard
WindowsService with running instance of Hangfire BackgroundJobServer

I would like to have a complete separation of view (dashbaord) form dll that actually executes a job running on windows service. From what I can see it's not currently possible.

[evollu]

@pawel31bielsko I'm trying the same setup.

@pieceofsummer
Can your point any IApplyStateFilters or IElectStateFilters that requires the job definition during the state change Scheduled->Enqueued? Most I've seen is just using metadata of the job.
Triggering a recurring job doesn't have to be like scheduling a regular job because the serialized job is already in storage. we can schedule a job recurring job data in database.

[pieceofsummer]

@evollu recurring jobs don't have Scheduled->Enqueued transition, as they're initially created in Enqueued state. Scheduled->Enqueued transition occurs only for delayed jobs (or when the job is being retried after exception).

I can't point any built-in filter, but you could easily imagine one. For example, an IClientFilter which would check method signature or attributes, and cancel job creation if needed. I've posted an example of such filter to check date interval for recurring jobs.

[evollu]

@pieceofsummer I see. There are certain cases where someone need to deserialize the job. (Can putting data in job parameter be an workaround?)
However if we can delay the deserialization until necessary, Hangfire will be able to be used by microservice architecture for basic usage. (in your example let the filter do deserialization?)

[snakenstein]

This behavior and the need of sharing the same codebase between job server and dashboard really surprised me. If this is by design, maybe think about changing that design?

[Tonvengo]

Is there any plans to change implementation?