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

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:

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.