Hangfire icon indicating copy to clipboard operation
Hangfire copied to clipboard

Add Source section to dashboard job details

Open epenet opened this issue 1 year ago • 2 comments
trafficstars

Currently there is no easy way to see what was extracted from the database.

We have three separate projects sharing a common abstraction dll:

  • one which creates jobs
  • one which runs jobs
  • one with the dashboard

We had an issue in which the job abstraction dll was out of date on the dashboard project and this caused great confusion as the description as the top did not match the content of the database due to deserialization/serialization using an older schema.

epenet avatar Mar 22 '24 11:03 epenet

Hm, can you share some more details about the issue you had before proceeding to the next steps?

odinserj avatar Mar 28 '24 09:03 odinserj

It's kind of hard to describe, so hopefully this makes sense.

We have two dlls:

  • BackgroundTask.Abstractions.dll
    • it contains a settings class JobSettings, a job interface IJob with a method IJob.Do(JobSettings settings)
    • v1 had a JobSettings.WorkflowID property to pass in a single integer
    • v2 removed this property to replace it with JobSettings.WorkflowIDList property to pass in a list of integers
  • BackgroundTask.Runner.dll has a Job class that implements the IJob interface

We have the following scenario:

  • Server 1 (latest versions) was used to create a job with JobSettings.WorkflowIDList = [1,2,3].
  • Server 2 (latest versions) was used the run the job, but sadly it failed for an unknown reason... which needs investigating.
  • Server 3 (obsolete versions) was used to instigate the failure via the dashboard. When we open the job details, the argument is displayed as {"WorkflowID": null}

We were very very confused and we spent a long time investigating Server 1 to understand why the argument was being passed wrong. Why did it seem to be using an older version of the abstraction dll when it had been correctly updated? After a while we decided to check the database, and we found that in the database, the argument was correctly set to ["{\"WorkflowIDList\": [1, 2, 3]}"]

That's when we (finally) understood that the issue was not on Server 1 creating the job with wrong settings, but instead with Server 3 displaying settings that were not in the database.

This patch adds a display for the raw database settings, which may or may not match the arguments displayed in the top section.

epenet avatar Mar 28 '24 11:03 epenet