Hangfire: Value defining max length for parameters should be configurable by the client

[emanuelmarques]

Greetings,

With the last update, we stoped being able to see the parameters of most of our jobs. We checked the line bellow and the max length is hardcoded. This value should be configurable by whoever uses hangfire.

Thank you

https://github.com/HangfireIO/Hangfire/blob/053afff4b7fcfa2be060760b14879c5ac7a93204/src/Hangfire.Core/Dashboard/JobMethodCallRenderer.cs#L32

[odinserj]

I understand that hard-coded values are bad, but could you add more details on what arguments you are using, why so large, and what number of max argument size you are planning to use?

[emanuelmarques]

@odinserj I use it to process complex objects and the parameters also have data about the workflow. The main purpose is to trace problems once a job fails and eventually re-inject the job with corrected parameters

[emanuelmarques]

@odinserj there is already a pull request for this: https://github.com/HangfireIO/Hangfire/pull/1302

[emanuelmarques]

@odinserj is there any vision on when this could be merged?

[odinserj]

@emanuelmarques, I really don't want to add yet another configuration option for this. What if I convert the MaxArgumentToRenderSize to a field and provide a method for changing it via reflection? In this case you will be able to change it without introducing a new option.

[emanuelmarques]

@odinserj If with that, I am able to provide the max / set unlimited max argument, I'm ok with it

[odinserj]

Thanks for your patience and understanding, @emanuelmarques. The change is landed to the master branch and will be available in 1.6.22 so you can use the following method to change the actual value. If anybody other wants to see it as an option, just vote :+1: for the first comment of this thread.

public static bool SetMaxArgumentToRenderSize(int value)
{
    var type = Type.GetType("Hangfire.Dashboard.JobMethodCallRenderer, Hangfire.Core", throwOnError: false);
    if (type == null) return false;

    var field = type.GetField("MaxArgumentToRenderSize", BindingFlags.Static | BindingFlags.NonPublic);
    if (field == null) return false;

    field.SetValue(null, value);
    return true;
}

[gmoreno90]

Hi guys,
I'm trying to use it and all the times have this error.
Cannot set initonly static field 'MaxArgumentToRenderSize' after type 'Hangfire.Dashboard.JobMethodCallRenderer' is initialized
What is the correct line where we need to change?
I tested on Program and on startup.
Many thanks in advance
Gon

[gmoreno90]

Hi @emanuelmarques this works for you?
Best regards
Gon

[DotJoshJohnson]

@gmoreno90:

I just happened to be investigating the same thing today. It turns out, the ability to set readonly fields was never truly reliable and this has been explicitly disabled in .NET Core: https://github.com/dotnet/runtime/issues/11571.

I would agree with @emanuelmarques that this should be exposed as an option, so I've added my vote above.

[emanuelmarques]

Hello @gmoreno90 @DotJoshJohnson

That actually worked for me and has been working for the past almost 2 years. I may be using an older version of .net core where that ability is still possible.

However, I currently have mixed feelings about this:
On one side, if hangfire allows big arguments to be passed to a job, it should be shown in the dashboard.
On the other side, maybe it would be a better practice to have that entity in the database, pass the id of the entity to the job, and the job would fetch the information from the DB.

Maybe both are right

⚖️

[DotJoshJohnson]

@emanuelmarques:

I actually agree that passing an ID to the job and keeping large entities in a data store is the goal to strive for. But some projects (like mine) find argument sizes suddenly getting larger due to other changes in the app. While I intend on eventually adjusting the architecture to store these arguments and pass in IDs, passing large arguments for now is something I'm willing to live with. I think exposing this limit as an option would be a solid stopgap solution.

A long-term solution to support these referenced entities in the dashboard might be to allow a delegate to be defined that retrieves entity data so the dashboard can offer the content up as a download. If @odinserj is open to this kind of addition, I'd be happy to submit a PR.

In the meantime as I needed to keep my current project moving, I chose to pass the entity into the job as a parameter as there appears to be no limit on size there and it is displayed nicely in the dashboard.

[odinserj]

Thank you for your patience and solid arguments. I've just removed the readonly keyword so the SetMaxArgumentToRenderSize method shown above should work fine. However I don't see how to make this feature to have first class support via the DashboardOptions class (since the JobMethodCallRenderer class itself is static) without introducing breaking changes. Changes will be released in version 1.7.19.

[gmoreno90]

Hi, many thanks for the update!! We will wait for this version. When stimate delivery?
Gon

[meshit]

Hi, how can i change the value of SetMaxArgumentToRenderSize to > 4096 in my code?
Running asp.net 4.5 xxx

Best regards Pelle

[odinserj]

Thanks everyone for participating, so I've added the IGlobalConfiguration.UseMaxArgumentSizeToRender extension method as it's the simplest way to expose this feature publicly without introducing breaking changes:

GlobalConfiguration.Configuration
    .UseMaxArgumentSizeToRender(4096) 
    .UseXXX()
    .UseYYY()
    .UseZZZStorage();

[gmoreno90]

Hi @odinserj many thanks and a happy new year!

[meshit]

Thank you ever so much! That really was great and superfast, i am so impressed! "Spatsiba muy drug"