Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Postgres connection leak: StartClient creates a new sqlstore.Container per (re)connect and never closes it

Đang mở
  • Có gì không ổn?
#165 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 5 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
68/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
go, postgresql
Lĩnh vực
backend, databases

Hướng nghiên cứu

Đọc pkg/whatsmeow/service/whatsmeow.go, tập trung vào StartClient ở dòng 322 và đường dẫn RestartInstance -> StartInstance ở dòng 237. Tái hiện các lần kết nối lại lặp đi lặp lại hoặc kiểm tra vòng đời của container, sau đó xác minh rằng các lần kết nối lại không còn để các pool database/sql ở trạng thái mở hoặc tích lũy các backend PostgreSQL.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

StartClient builds a fresh sqlstore.Container at pkg/whatsmeow/service/whatsmeow.go:322 on every call. The container is a local variable and is never closed — there is no container.Close() anywhere in the file. Each call therefore leaks a whole database/sql pool.

This is not limited to the first connect: RestartInstance ends in Starting fresh instance -> StartInstance -> StartClient (whatsmeow.go:237), and WhatsApp drops the websocket on its own several times a day (Got 503 stream error, failed to read frame header: EOF), each drop triggering Disconnected detected, restarting instance.

Measured

v0.7.2, Postgres 15.6, a single connected instance, nobody using the panel: 17 backends on evogo_auth accumulated over 18h, with zero GET /instance/qr in the window.

  • Connections appear in pairs — the MaxIdleConns default of database/sql — and their backend_start timestamps match the restart lines in the log to the second.
  • 6 reconnects in 18h, so ~16 connections/day: max_connections=100 exhausted in ~6 days. We hit that twice.
  • Once exhausted, QR generation stops and sendText returns 500. The server then reconnects in a loop (11 Starting fresh instance in 80 seconds), burning whatever is left, so the saturation looks sudden.
  • It scales with instance count — ten numbers would saturate in half a day.

Requesting QR is just another path into the same StartClient, so /instance/qr makes it faster but is not the cause.

Suggested fix

Create the container once per process (the DSN never changes) and reuse it, or keep a reference per instance and Close() the old one before starting fresh.

Workaround

For anyone hitting this before a fix lands:

ALTER DATABASE evogo_auth SET idle_session_timeout = '1h';

Postgres then reaps the orphaned pools. Safe for live sessions: credentials live in the whatsmeow_* rows, not in the TCP connection, and pgx discards a dead connection silently before use. Took us from 17 backends to 6 with no disconnect and no re-pairing.

Ngôn ngữ chính
Go
Star
890
Fork
473
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

  • Có Dockerfile hoặc tệp Docker Compose
  • Có mẫu pull request
  • Không có hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của evolution-foundation/evolution-go

Tất cả issue của evolution-foundation/evolution-go

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.