[16.0] queue_job: Jobs are stuck in "Enqueued" when created while installing / updating modules

[baguenth]

Jobs are stuck in "Enqueued" when created while installing / updating modules

Module

queue_job

Describe the bug

Since the last update (16.0.2.12.0) there is an issue with queue jobs.
Jobs are stuck in "Enqueued" when they have been created while installing / updating modules.

Creating jobs in a running system via user action is working fine. But if queue jobs are created in a migration or post-init script while updating / installing a module, those jobs are stuck in "Enqueued".

The stuck jobs hold up all other jobs created afterwards. The only resolution is to manually requeue the stuck jobs.

The issue was not there in 16.0.2.11.5, therefore i suspect #794 to cause the issue.

To Reproduce

Affected versions:

Steps to reproduce the behavior: 16.0.2.12.0

1. Add a migration script in an already installed module which creates queue jobs or Add a module which creates queue jobs in a post-init script.
2. Update / Install the module
3. You will see jobs in the job queue which are stuck in "Enqueued".

Expected behavior
Jobs should never be stuck in "Enqueued", regardless i they come from an update, installation or regular user action.

Additional context
Add any other context about the problem here. (e.g. OS, Python version, ...)

[baguenth]

Hey @florentx and @sbidoul,

fyi.

[sbidoul]

You probably need #874 which has the dead jobs requeuer.

But the only way they got in enqueued state in the first place is that the job runner was running. Did you have a live instance running elsewhere why your migration was running?

[baguenth]

Actually in my case it was not a migration but a new module which was installed in a running environment. In the post-init script we create some queue jobs. After checking the logs i figured out something interesting.

2026-01-23 10:19:49,590 1 INFO ? odoo.addons.queue_job.jobrunner.runner: asking Odoo to run job 6b5176d7-83bf-4a82-b6c6-8ee236a8c022 on db ?
2026-01-23 10:19:49,614 1 ERROR ? odoo.http: Exception during request handling.
Traceback (most recent call last):
  File "/opt/odoo/venv/lib/python3.12/site-packages/odoo/http.py", line 2071, in __call__
    response = request._serve_db()
               ^^^^^^^^^^^^^^^^^^^
  File "/opt/odoo/venv/lib/python3.12/site-packages/odoo/http.py", line 1658, in _serve_db
    return service_model.retrying(self._serve_ir_http, self.env)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/odoo/venv/lib/python3.12/site-packages/odoo/service/model.py", line 152, in retrying
    result = func()
             ^^^^^^
  File "/opt/odoo/venv/lib/python3.12/site-packages/odoo/http.py", line 1686, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/odoo/venv/lib/python3.12/site-packages/odoo/http.py", line 1800, in dispatch
    return self.request.registry['ir.http']._dispatch(endpoint)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/odoo/venv/lib/python3.12/site-packages/odoo/addons/base/models/ir_http.py", line 154, in _dispatch
    result = endpoint(**request.params)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/odoo/venv/lib/python3.12/site-packages/odoo/http.py", line 734, in route_wrapper
    result = endpoint(self, *args, **params_ok)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/odoo/venv/lib/python3.12/site-packages/odoo/addons/queue_job/controllers/main.py", line 110, in runjob
    job = Job.load(env, job_uuid)
          ^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/odoo/venv/lib/python3.12/site-packages/odoo/addons/queue_job/job.py", line 228, in load
    return cls._load_from_db_record(stored)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/odoo/venv/lib/python3.12/site-packages/odoo/addons/queue_job/job.py", line 303, in _load_from_db_record
    method = getattr(recordset, method_name)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'product.template' object has no attribute 'update_rankings_preferred_jobs'
2026-01-23 10:19:49,618 1 INFO ? werkzeug: 127.0.0.1 - - [23/Jan/2026 10:19:49] "GET /queue_job/runjob?db=?&job_uuid=6b5176d7-83bf-4a82-b6c6-8ee236a8c022 HTTP/1.1" 500 - 6 0.003 0.020
2026-01-23 10:19:49,618 1 ERROR ? odoo.addons.queue_job.jobrunner.runner: exception in GET http://localhost:8069/queue_job/runjob?db=?&job_uuid=6b5176d7-83bf-4a82-b6c6-8ee236a8c022
Traceback (most recent call last):
  File "/opt/odoo/venv/lib/python3.12/site-packages/odoo/addons/queue_job/jobrunner/runner.py", line 218, in urlopen
    response.raise_for_status()
  File "/opt/odoo/venv/lib/python3.12/site-packages/requests/models.py", line 1021, in raise_for_status
    raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 500 Server Error: INTERNAL SERVER ERROR for url: http://localhost:8069/queue_job/runjob?db=?&job_uuid=6b5176d7-83bf-4a82-b6c6-8ee236a8c022
2026-01-23 10:19:51,291 1 INFO ? odoo.modules.registry: Reloading the model registry after database signaling.
2026-01-23 10:19:51,296 1 INFO ? odoo.modules.loading: loading 1 modules...
2026-01-23 10:19:51,302 1 INFO ? odoo.modules.loading: 1 modules loaded in 0.01s, 0 queries (+0 extra)
2026-01-23 10:19:51,334 1 INFO ? odoo.modules.loading: loading 728 modules...

Seems like the job runner starts running the job before the registry was reloading and database signaling happend.
Therefore the job runner is running with old code and doesn't know about the new function in 'product.template'.
Interestingly the job doesn't fail, even though there is an exception while running it. So i only figured out about the error when checking server logs.

When requeuing the job directly after the module installation is done, everything runs smoothly.

I never saw such an issue before when using queue_jobs in the last couple of years. Was there some change lately in queue_job which could affect the timing?

[sbidoul]

I never saw such an issue before when using queue_jobs in the last couple of years. Was there some change lately in queue_job which could affect the timing?

Not that I know of. A job can start as soon as it is committed and that's always been so.

[baguenth]

To overcome this race condition, best practise could be to always put an eta for jobs created in an installation / Migration scenario.

Still i am confused why this issue popped up now. Maybe the job runner is a little bit faster after the last refactoring what could lead to race conditions.

[sbidoul]

Are there commits in your post-init scripts? Or maybe there is some race condition in the Odoo module installation logic where it would commit before doing the database signaling to trigger registry reload in other workers?

[baguenth]

No, we do not use explicit commits in post-init, and we haven’t customized the installation logic in any way.

My colleagues have confirmed that they observe the same issue with post-migrate scripts. The situation is the same on our side as well: we neither customized the update flow nor use explicit commits.

[sbidoul]

Still I don't see how queue_job would be special, it just do an http request to start the job. The only particularity is that it's going to do it very shortly after the commit that created the job, but it could be any other requests coming in during the installation process.

[baguenth]

I am also confused, tbh. The pragmatic solution on our end is, to delay execution of all queue jobs created in migration / installation scenarios by using an eta (now + 30 secs).

[amh-mw]

The pragmatic solution on our end is, to delay execution of all queue jobs created in migration / installation scenarios by using an eta (now + 30 secs).

I believe that not self.pool.ready could be used as a litmus to detect migration / installation, so this solution could be baked in as a guard.