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

Instance settings silently reset to defaults (rabbitmqEnable, events, flags) without container restart

Đang mở
  • Có gì không ổn?
#111 0 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ó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
48/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, rabbitmq
Lĩnh vực
api, backend, databases

Hướng nghiên cứu

Bắt đầu bằng cách lần theo các handler phía sau GET /instance/all và PUT /instance/{id}/advanced-settings, sau đó kiểm tra các luồng persistence và reconnect được chạy khi một instance đang hoạt động. Tái hiện việc settings bị reset đã được báo cáo và kiểm tra xem các bản cập nhật một phần có ghi đè các trường bị bỏ qua bằng giá trị mặc định hay không. Được xem là hoàn tất khi settings đã lưu vẫn không thay đổi nếu không có cập nhật rõ ràng và luồng reset phát ra cảnh báo có thể hành động; điều tra /instance/qr riêng.

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

Mô tả

bug
Welcome!
  • Yes, I have searched for similar issues on GitHub and found none.
What did you do?
  1. Created an instance via Manager and connected it via QR code.
  2. Configured the instance through the Manager:
    • RabbitMQ: Enabled
    • Events: ALL (which produced MESSAGE,SEND_MESSAGE,READ_RECEIPT,PRESENCE,HISTORY_SYNC,CHAT_PRESENCE,CALL,CONNECTION,LABEL,CONTACT,GROUP,NEWSLETTER,QRCODE,BUTTON_CLICK,PICTURE,USER_ABOUT)
    • Advanced settings: alwaysOnline, rejectCall, readMessages, ignoreGroups, ignoreStatus all set to true
  3. Verified the configuration was persisted via GET /instance/all. Everything was correct.
  4. The setup worked as expected for several hours. Messages were published to the
    {instanceId}.message, {instanceId}.sendmessage and {instanceId}.receipt queues,
    and consumed successfully by n8n.
  5. Left it running overnight. Did not restart the container. Did not touch the Manager.
  6. The next morning, checked GET /instance/all again.
What did you expect?

The instance configuration should persist as long as it is not explicitly changed.

Specifically, I expected rabbitmqEnable, events and the advanced settings flags
to remain exactly as I had saved them.

What did you observe instead of what you expected?

All instance settings had silently reverted to their default values, without any
container restart and without any API call from my side.

Comparison of GET /instance/all before and after:

Field Before (configured) After (reset)
rabbitmqEnable "enabled" ""
events MESSAGE,SEND_MESSAGE,READ_RECEIPT,PRESENCE,HISTORY_SYNC,... MESSAGE
alwaysOnline true false
rejectCall true false
readMessages true false
ignoreGroups true false
ignoreStatus true false

Critical consequence: because rabbitmqEnable was silently cleared, the instance
stopped publishing any event to RabbitMQ. My entire downstream pipeline went dead
with no error, no log line, and no warning. The queues simply stopped receiving messages.

At the same time, the instance disconnected from WhatsApp and entered an infinite
reconnection loop (disconnect_reason: "Reconnecting"). While in this state,
the QR code endpoint never returned a code, so the instance could not be re-paired.

docker compose restart evolution-go cleared the reconnection loop, but the
configuration had to be re-entered manually through the Manager.

Important: the container had 32 hours of uptime at the moment I observed the
reset (docker compose ps confirms). So this was not caused by a restart or a
fresh boot — the running process reset its own persisted configuration.

Two possibly separate issues here:

  1. Instance configuration being reset without a restart (this is the serious one).
  2. /instance/qr never returning a QR while the instance is stuck in Reconnecting.

I cannot rule out that the WhatsApp disconnection itself is caused by my phone number,
which has a long history of re-pairing (jid shows device ID :41). But a bad phone
number should not cause the API to wipe its own configuration from the database.

Screenshots/Videos

No response

Which version are you using?

0.7.2

What is your environment?

Linux

If applicable, paste the log output

evolution-go | 2026/07/13 09:19:30 [WARN] [] Client disconnected on attempt 2/2, attempting reconnection...
evolution-go | 2026/07/13 09:19:35 [WARN] [] Client disconnected on attempt 1/2, attempting reconnection...
evolution-go | 2026/07/13 09:19:44 [WARN] [] Client disconnected on attempt 2/2, attempting reconnection...
evolution-go | 2026/07/13 09:19:51 [WARN] [] Client disconnected on attempt 1/2, attempting reconnection...
evolution-go | 2026/07/13 09:20:00 [WARN] [] Client disconnected on attempt 2/2, attempting reconnection...

Note: this loop repeated indefinitely. No log line was emitted when the settings were reset — that is part of the problem.

Additional Notes

Environment

  • Evolution GO 0.7.2 (Docker image evoapicloud/evolution-go:0.7.2, pinned tag)
  • Ubuntu 24.04, Docker Compose
  • PostgreSQL 16 (postgres:16-alpine), named volume, healthy the whole time
  • RabbitMQ 3.13 (rabbitmq:3.13-management-alpine), healthy the whole time
  • DATABASE_SAVE_MESSAGES=true, AMQP_URL set and validated on boot
  • Nginx reverse proxy with TLS
  • Single instance running

Both Postgres and RabbitMQ were healthy and had continuous uptime — the database
was never unavailable, so this does not look like a failed read falling back to defaults.

Why this matters

This is being used for a public health research project (medication adherence
reminders). A silent configuration reset means patient responses stop being recorded
with no visible failure. Silent failure is significantly worse than a crash — a crash
can be detected and alerted on.

Suggestions

  • Log a WARN/ERROR whenever instance settings are written or reset.
  • Never allow a write path to reset rabbitmqEnable/events to defaults implicitly;
    only change what was explicitly requested.
  • Related observation: PUT /instance/{id}/advanced-settings also resets any field
    not present in the request body to false, instead of leaving it untouched.
    A partial update should not clear unrelated fields. This may be the same root cause.

I'm happy to provide more details or test a patch.

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.