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

[BUG] chats.update / initial history sync discard the archived flag before it reaches webhooks or the database

Đang mở
#2,743 1 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
67/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
postgresql, typescript
Lĩnh vực
api, backend, databases

Hướng nghiên cứu

Start in whatsapp.baileys.service.ts and compare the chats.update and messaging-history.set handlers with the compiled path cited in the issue. Then inspect the Prisma Chat model and the findChats flow. Done means archived state reaches webhook payloads, persists on Chat rows, and is returned by findChats, with the relevant migration and tests or reproduction checks passing.

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

Mô tả

📋 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

  1. Connect an instance (WHATSAPP-BAILEYS) with the chats.update webhook enabled.
  2. Archive (or unarchive) any chat directly on the linked phone.
  3. Inspect the delivered chats.update webhook payload.
  4. 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:

  1. Add archived Boolean @default(false) to the Chat Prisma model (migration).
  2. In chats.update, forward archived: chat.archived in the webhook payload and include it in the chat.updateMany write.
  3. 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.
  4. 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.

Ngôn ngữ chính
TypeScript
Star
9.9k
Fork
7.4k
Chỉ số merge pull request
Không có pull request nào được merge trong 30 ngày

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

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-api

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

Issue tương tự

Thêm issue về TypeScript

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.