We recently upgraded a project from to 2.x and found that all of the extant jobs were not being executed. It appears that the job_schema_version was still set to 1. This meant the new workers would ignore the enqueued jobs.
To get all the jobs running, we ran the following migration:
UPDATE que_jobs
SET job_schema_version = 2
WHERE job_schema_version IS DISTINCT FROM 2
I can imagine there is a rationale for this, such as to allow gradual no-downtime migration from one version to another. But it seems to have bitten a few people. Certainly us, a few here hlascelles/que-scheduler#412, and maybe this one #381.
Is there somewhere in the docs that we should put this as a debug step? And/or should it go in the migrate guide here: https://github.com/que-rb/que/blob/c0b0be8dc60ff18ea6a76a553ec38a273c303de3/docs/README.md#migrating
If nothing else, maybe this issue can live as a debug pointer.
We recently upgraded a project from to 2.x and found that all of the extant jobs were not being executed. It appears that the
job_schema_versionwas still set to 1. This meant the new workers would ignore the enqueued jobs.To get all the jobs running, we ran the following migration:
I can imagine there is a rationale for this, such as to allow gradual no-downtime migration from one version to another. But it seems to have bitten a few people. Certainly us, a few here hlascelles/que-scheduler#412, and maybe this one #381.
Is there somewhere in the docs that we should put this as a debug step? And/or should it go in the migrate guide here: https://github.com/que-rb/que/blob/c0b0be8dc60ff18ea6a76a553ec38a273c303de3/docs/README.md#migrating
If nothing else, maybe this issue can live as a debug pointer.