Set max_job_runtime in TaskJob instead of hijacking JobIteration's global config about maintenance_tasks

[etiennebarrie]

It's possible to set the value in the application initializers because it's a ||=, that's why it's an after_initialize BTW. It doesn't pollute the global config because it respects it. Even something in after_initialize can be tweaked because after_initialize run in the railties order and the application is typically the last railtie, so an after_initialize from the application would override it, but it's not even necessary with the ||=.

We didn't use that option because it didn't exist at the time in job-iteration. We could use it, but you can also use it in your own custom job directly, so I'm not sure it's worth it if it means any breaking change here.

[etiennebarrie]

Also that commit hasn't been released yet, so we still can't use it. And there's an issue with the implementation, it breaks JobIteration.max_job_runtime as far as I can see.

Edit: no it's fine because the global value is in the included hook.

[adamzapasnik]

It's an old commit, thought it's been released already, sorry.

Well, after_initialize is necessary if you want max_job_runtime to stay nil. 🤔

Anyway, I agree it seems it's not worth the effort to introduce such change if no one else has complained. I'll close it, thank you for you time and help.