Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[19.0] queue_job: Jobs stay pending after the jobrunner's database connection is silently dropped

Abierto
  • ¿Algo no está bien?
#984 1 comentario 1 reacción 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@HoloborodkoBohdan ya está trabajando en esto.

Desde el 28/9/2026.

  • #1000 de @HoloborodkoBohdan — abierto

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
25/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Estancado
Stack tecnológico
postgresql, python
Área
backend

Línea de trabajo

The issue points to queue_job/jobrunner/runner.py, specifically _connection_info_for() and QueueJobRunner.run(). Review how connection parameters are assembled and how the runner handles a lost connection; the issue proposes enabling TCP keepalives with defaults. An open linked pull request already addresses this issue, so check that work before making changes.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug

Module

  • queue_job

Describe the bug

The jobrunner keeps one database connection open for as long as it runs, and it holds
the master lock on that connection.

If that connection dies without the server telling the client (a network problem, or a
database failover), two things happen:

  • PostgreSQL drops the lock, because the session is gone.
  • The runner does not notice. Its socket still looks open, so it just waits forever.

From then on no jobs are dispatched at all. Nothing is logged. The process looks healthy.
Only restarting Odoo fixes it.

The runner already has code to reconnect if the database connection breaks (the
except Exception block in run()), but it never runs, because nothing raises an error.
The runner is simply stuck waiting.

To Reproduce

Affected versions: 19.0

Steps to reproduce the behavior:

  1. Start Odoo with queue_job in server_wide_modules (odoo.conf). Check the runner has the lock:
    SELECT count(*) FROM pg_locks WHERE locktype = 'advisory'; should return 1.
  2. Break the connection silently, so the client is never told. For example, add a firewall
    rule that drops traffic between Odoo and PostgreSQL. (Using pg_terminate_backend will
    not work, because that tells the client.)
  3. Add a job. It stays pending forever. The lock count is now 0, and nothing appears in
    the log.

Expected behavior
The runner should notice the connection is dead and reconnect, which is what the
except Exception block is already there to do.

zooming in to the except Exception mentioned:
QueueJobRunner.run() in queue_job/jobrunner/runner.py.
The outer loop wraps initialize_databases() and the processing loop in a try/except,
and the last of its four handlers is:

except Exception:
    _logger.exception("exception: sleeping %ds and retrying", ERROR_RECOVERY_DELAY)
    self.close_databases()
    time.sleep(ERROR_RECOVERY_DELAY)

Additional context

  • Running Odoo in AWS ECS and Aurora PostgreSQL.
  • Odoo WEB service and CRON service separated
  • Both web and cron service has server_wide_modules = queue_job
  • cron service has http_enable = False and runs on a different port

Proposed Fix:
In queue_job/jobrunner/runner.py, at the end of
_connection_info_for(), just before the return:

# added
connection_info.setdefault("keepalives", 1)
connection_info.setdefault("keepalives_idle", 60)
connection_info.setdefault("keepalives_interval", 10)
connection_info.setdefault("keepalives_count", 5)

The fix is to turn on TCP keepalives there, so a dead connection is noticed after about a
minute instead of never.

Lenguaje dominante
Python
Estrellas
271
Forks
602
Merge medio
4 d 4 h
PR fusionados (30 d)
6

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de OCA/queue

Todos los issues de OCA/queue

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.