Several thousand jobs were in queue at the time of deploy and started rapidly failing because they weren't stored with the parameter. It would have been an easier transition to allow those jobs to run as is, and just take the default value of the parameter.
If it's not that way already, job parameters which are no longer present in the definition should also not prevent the job from running. Perhaps this means there should be an "unknown parameters hash" or something similar, following the pattern of StdLib's JSONSerializable.
Today I added an optional parameter to a job:
Several thousand jobs were in queue at the time of deploy and started rapidly failing because they weren't stored with the parameter. It would have been an easier transition to allow those jobs to run as is, and just take the default value of the parameter.
If it's not that way already, job parameters which are no longer present in the definition should also not prevent the job from running. Perhaps this means there should be an "unknown parameters hash" or something similar, following the pattern of StdLib's JSONSerializable.
Crystal version: 0.28.0 Mosquito Shard version: 0.4.0