📋 Bug Description
When a chat is archived/unarchived on the phone (or any linked device), Baileys emits the change via chats.update with an archived: true/false field. Evolution's chats.update handler in whatsapp.baileys.service.ts (WHATSAPP-BAILEYS integration) discards every field except remoteJid before forwarding to the webhook or writing to the DB:
"chats.update": async (e) => {
const chatsRaw = e.map(chat => ({ remoteJid: chat.id, instanceId: this.instanceId }));
this.sendDataWebhook('chats.update', chatsRaw);
for (const chat of e)
await this.prismaRepository.chat.updateMany({
where: { instanceId: this.instanceId, remoteJid: chat.id, name: chat.name },
data: { remoteJid: chat.id },
});
}
(from compiled dist/api/integrations/channel/whatsapp/whatsapp.baileys.service.js, v2.3.7)
The messaging-history.set handler (emits chats.set) does the same trim, and additionally only forwards chats not already in the Chat table — so even a fresh reconnect can't backfill archive state for chats Evolution already knows about.
The Chat Postgres table also has no archived column at all:
Table "public.Chat"
id | remoteJid | labels | createdAt | updatedAt | instanceId | name | unreadMessages
So there is currently no way for an integrator to learn a chat's real archived state via webhook, DB, or GET /chat/findChats/:instance — it's dropped at the earliest point in Evolution's own pipeline.
🔄 Steps to Reproduce
- Connect an instance (WHATSAPP-BAILEYS) with the
chats.update webhook enabled.
- Archive (or unarchive) any chat directly on the linked phone.
- Inspect the delivered
chats.update webhook payload.
- Check the
Chat row for that remoteJid via GET /chat/findChats/:instance or Postgres directly.
✅ Expected Behavior
chats.update carries the chat's current archived boolean, it's persisted on the Chat row, and findChats returns it — so integrators can mirror the phone's real archived list instead of maintaining a local-only flag.
❌ Actual Behavior
chats.update/chats.set payloads only ever contain {remoteJid, instanceId[, name]}. archived is silently discarded.
🌍 Environment
- OS: Ubuntu (Docker host)
- Evolution API version: 2.3.7
- Integration: WHATSAPP-BAILEYS
- Database: PostgreSQL 13
📝 Additional Context / Proposed Fix
Sketch of a fix, for whoever picks this up:
- Add
archived Boolean @default(false) to the Chat Prisma model (migration).
- In
chats.update, forward archived: chat.archived in the webhook payload and include it in the chat.updateMany write.
- In
messaging-history.set, same field addition; consider also letting already-known chats' archived/pinned/muteEndTime refresh on reconnect, since today only brand-new chats get forwarded at all.
- Confirm
findChats selects/returns the new column once it exists.
Related: #2495 looks like a different symptom in the same area (write-side archiveChat endpoint erroring) — this is the read side: archive state never reaching the integrator in the first place.
📋 Bug Description
When a chat is archived/unarchived on the phone (or any linked device), Baileys emits the change via
chats.updatewith anarchived: true/falsefield. Evolution'schats.updatehandler inwhatsapp.baileys.service.ts(WHATSAPP-BAILEYS integration) discards every field exceptremoteJidbefore forwarding to the webhook or writing to the DB:(from compiled
dist/api/integrations/channel/whatsapp/whatsapp.baileys.service.js, v2.3.7)The
messaging-history.sethandler (emitschats.set) does the same trim, and additionally only forwards chats not already in theChattable — so even a fresh reconnect can't backfill archive state for chats Evolution already knows about.The
ChatPostgres table also has noarchivedcolumn at all:So there is currently no way for an integrator to learn a chat's real archived state via webhook, DB, or
GET /chat/findChats/:instance— it's dropped at the earliest point in Evolution's own pipeline.🔄 Steps to Reproduce
chats.updatewebhook enabled.chats.updatewebhook payload.Chatrow for thatremoteJidviaGET /chat/findChats/:instanceor Postgres directly.✅ Expected Behavior
chats.updatecarries the chat's currentarchivedboolean, it's persisted on theChatrow, andfindChatsreturns it — so integrators can mirror the phone's real archived list instead of maintaining a local-only flag.❌ Actual Behavior
chats.update/chats.setpayloads only ever contain{remoteJid, instanceId[, name]}.archivedis silently discarded.🌍 Environment
📝 Additional Context / Proposed Fix
Sketch of a fix, for whoever picks this up:
archived Boolean @default(false)to theChatPrisma model (migration).chats.update, forwardarchived: chat.archivedin the webhook payload and include it in thechat.updateManywrite.messaging-history.set, same field addition; consider also letting already-known chats'archived/pinned/muteEndTimerefresh on reconnect, since today only brand-new chats get forwarded at all.findChatsselects/returns the new column once it exists.Related: #2495 looks like a different symptom in the same area (write-side
archiveChatendpoint erroring) — this is the read side: archive state never reaching the integrator in the first place.