[19.0] queue_job: Jobs stay pending after the jobrunner's database connection is silently dropped
Maintainer thường phản hồi trong vòng 1 ngày
@HoloborodkoBohdan đang làm issue này rồi.
Từ ngày 28/9/2026.
- #1000 của @HoloborodkoBohdan — đang mở
Đánh giá
- Độ khó
- 2/5
- Thời gian dự kiến
- 1-3 giờ
- Mức phù hợp với người mới
- 25/100
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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:
- Start Odoo with
queue_jobinserver_wide_modules(odoo.conf). Check the runner has the lock:
SELECT count(*) FROM pg_locks WHERE locktype = 'advisory';should return 1. - Break the connection silently, so the client is never told. For example, add a firewall
rule that drops traffic between Odoo and PostgreSQL. (Usingpg_terminate_backendwill
not work, because that tells the client.) - Add a job. It stays
pendingforever. 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.
- Ngôn ngữ chính
- Python
- Star
- 271
- Fork
- 602
- Merge trung bình
- 4 ngày 4 giờ
- Pull request đã merge (30 ngày)
- 6
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của OCA/queue
-
enhancement
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 30/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Migration to version 20.0Đang mởhelp wanted no stale work in progress
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
OCA/queue#1002 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Delaying unlink or write on a model whose method was replaced raises AttributeError at enqueue timeCó thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mởbug
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
Maintainer thường phản hồi trong vòng 1 ngày
-
enhancement
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
Maintainer thường phản hồi trong vòng 1 ngày
-
[RFC] relative channel capacityĐang mởenhancement
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
OCA/queue#964 · 1 bình luận · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
Issue tương tự
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
BCDA-APS/polar-bits#93 ·
-
infer_audio_type only recognises one MPEG Layer III frame header, so most MP3 files are rejectedCó thể đã có người làm @Steve-20-ai đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
[BUG] - ssh_config `Match tagged` statement always appliesCó thể đã có người làm @AtharvRG đã nhận hôm nay. Đang mởBug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
paramiko/paramiko#2715 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 9 ngày
-
auto-rejected intake mcp-intake needs-salvage priority:high type:feature
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
Ikalus1988/MisakaNet#4221 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày