Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Lookup global
max_job_runtime
at runtime
The existing approach set `JobIteration.max_job_runtime` as the default value of the `job_iteration_max_job_runtime` `class_attribute`. However, this approach would close around the value at the time the `Iteration` module was included in the host `class`. This means that if a job class is defined before the host application sets `max_job_runtime`, the setting will not be honoured. For example, if using the `maintenance_tasks` gem, which defines a `TaskJob`, the default would be read when the gem is loaded, prior to initializers running, which is where the host application typically sets the global `max_job_runtime`. This commit removes the static default passed the `class_attribute`, and instead overrides the reader it provides with an implementation that delegates to `JobIteration.max_job_runtime`, ensuring we use the current global value at runtime. It should be noted that this does mean it's possible for the restriction on _increasing_ the `max_job_runtime` to fail to hold: ```ruby class MyJob < ApplicationJob include JobIteration::Iteration self.job_iteration_max_job_runtime = 1.hour # ... end JobIteration.max_job_runtime = 1.minute ``` but this is unlikely to occur in practice outside of jobs classes provided by gems (as the host app's classes would be defined after setting the global max in an initializer), but gems probably should be making decisions about max job runtime anyway.
- Loading branch information