First of all let me start with saying that I absolutely love hangfire.
I was wondering if it’s possible to add some kind of metadata to the hangfire jobs - the hangfire dashboard does the job well showing what went right or wrong, but all it displays is the job id (which is internal to hangfire) and the fired method name (which is a little cryptic).
What I am lookng for is a way to add some description to the job so that additional info can be passed and later it is easier to see what the job was all about.
This description could just be a string that is passed with the rest of the parameters to the recurring job (but then the recurring jobs would all have the same description), or instead of passing an action, a Func could be passed, having the resulting string saved with the suceeded job (but then the string will not be available for failed jobs).
Anyway, I would see that as a very useful feature. Maybe there is something I can do myself, extending the existing code?
Please let me know, thanks.
Have you checked out the DisplayName attribute?
1 Like
I could not find that feature in the documentation and it is exactly what I was looking for. Thanks!
So I used that option and it generally works well - one glitch that I am getting is that all string parameters are wrapped in double quotes. So for DisplayName
Update products {1} in {2} to {3} items
I am getting
Update products “RegularPrice” in “all locations” to 3 items
whereas I would expect
Update products RegularPrice in all locations to 3 items
Is that by design? I previously used 1.1.1 but I updated to 1.3.4 and I see that effect in both.
This is because HtmlHelper.DisplayJob method does not deserialize arguments from JSON, so string arguments are enclosed with quotes. I don’t think it will be a good idea to deserialize them just to display job in tables (some people may pass very large objects there). What do you think?
As a workaround you can provide method overloads and give them names like “Update products RegularPrice in all locations to {0} items”.
The method overloads does not really come into play as the amount of combinations is too high.
In the end, from my viewpoint this is only a minor glitch - having the possibility to describe the task helps me a lot and the quotes are not a problem other than the text looks like written by Joey who does not understand air quotes: https://www.youtube.com/watch?v=bW8OkSJvhvE
If you feel that this is how it should be because of performance considerations than I can perfectly live with that.
Ahaha, nice video 
From the other hand, we can made a special case for string arguments, and de-serialize only them. So, other arguments will be not deserialized. And everyone will be happy. Would you like to create a pull request for that (for the dev branch)?
Sure, I might do it, but it this thing is really low on my priority list right now so it will probably wait a while.
Thanks,
Michal
Not a problem, Michal, I totally understand you!
From the other hand, we can made a special case for