[BUG] chats.update / initial history sync discard the archived flag before it reaches webhooks or the database
メンテナーはふだん 5 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 67/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- postgresql, typescript
調査の方向性
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.
索引モデルが issue の本文から書いたものです。
説明
📋 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.updatewebhook enabled. - Archive (or unarchive) any chat directly on the linked phone.
- Inspect the delivered
chats.updatewebhook payload. - Check the
Chatrow for thatremoteJidviaGET /chat/findChats/:instanceor 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 theChatPrisma model (migration). - In
chats.update, forwardarchived: chat.archivedin the webhook payload and include it in thechat.updateManywrite. - In
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. - Confirm
findChatsselects/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.
- 主要言語
- TypeScript
- スター
- 9.9k
- フォーク
- 7.4k
- PR マージ指標
- 30日以内にマージされた PR はありません
環境構築
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
evolution-foundation/evolution-api のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
evolution-foundation/evolution-api#2723 ·
メンテナーはふだん 5 日以内に返信
-
難易度 1/5 1〜3時間 初心者へのやさしさ 88/100
evolution-foundation/evolution-api#2704 ·
メンテナーはふだん 5 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
evolution-foundation/evolution-api#2702 · コメント 2 件 · リアクション 3 件 ·
メンテナーはふだん 5 日以内に返信
-
[BUG] Cloud API: a single unknown wamid in a `statuses` batch silently drops the whole batch (`return` instead of `continue`)対応中かも @vin1i が 61 日前に担当しました。 オープン
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
evolution-foundation/evolution-api#2700 · コメント 1 件 ·
メンテナーはふだん 5 日以内に返信
-
[BUG] Chatwoot integration duplicates messages when a device re-delivers the same key.id — getExistingSourceIds exists but is never called on the live path対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
evolution-foundation/evolution-api#2675 ·
メンテナーはふだん 5 日以内に返信
evolution-foundation/evolution-api の issue をすべて見る
似ている issue
-
fix(worker): keep normal prepare waiting states failure-free対応中かも @LichKing-2234 が今日担当しました。 オープンagent:codex priority:P1
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
AgoraIO-Extensions/agent-infra#3745 ·
メンテナーはふだん 1 日以内に返信
-
The five-line work window can drop its oldest line: the per-line byte share ignores the JSON framing対応中かも @Eapp1e が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
makecindy/cindy#7973 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
難易度 1/5 1時間未満 初心者へのやさしさ 78/100
lingdojo/kana-dojo#33337 · コメント 1 件 · リアクション 5 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
code-yeongyu/senpi#4917 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信