fix: preserve unreadCount when inserting chats via messaging-history.set

[zcag]

Problem

When a new instance connects and Baileys fires messaging-history.set to bulk-import chat history, the chatsRaw entries are built with only remoteJid, remoteLid, instanceId, and name. The chat.unreadCount field — which WhatsApp's server sends in the history sync payload (Conversation.unreadCount, protobuf field #6) — is silently dropped.

As a result, every chat inserted through this path gets unreadMessages = 0 (the Prisma column default), regardless of the actual unread state on the server. The findChats endpoint then returns unreadCount: 0 for all historically-synced chats, even when the user has genuine unread messages.

Root cause

The CHATS_UPSERT insert path mapped the field (coercing missing values to 0):

unreadMessages: chat.unreadCount !== undefined ? chat.unreadCount : 0,

The messaging-history.set handler simply never included the equivalent mapping, so chat.unreadCount was dropped for every historically-synced chat.

Fix

• Extract a shared ChatRaw type so the raw chat objects built for both insert paths stay in sync as fields are added.
• In the messaging-history.set handler, include unreadMessages: chat.unreadCount in the chatsRaw.push(...) call (previously dropped).
• Align the CHATS_UPSERT insert path to the same chat.unreadCount form: pass the value through as-is — i.e. undefined when the server didn't send a count — and let the Prisma column default apply, rather than coercing to 0. This keeps both paths consistent and preserves the distinction between "server explicitly reported 0 unread" and "no unread count provided".

Testing

1. Create a fresh instance and scan QR code
2. Let messaging-history.set fire during initial sync
3. Call POST /chat/findChats/{instance} — chats should now reflect the server-side unread counts instead of all returning unreadCount: 0

Summary by Sourcery

Bug Fixes:

• Include unread message count from Conversation.unreadCount when building chats inserted during history sync, instead of defaulting all imported chats to zero unread messages.

[sourcery-ai]

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

Preserves WhatsApp server-provided unread counts when importing chats via the messaging-history.set handler by propagating chat.unreadCount into the Prisma chat.unreadMessages field, aligning behavior with the existing chats.upsert path.

Sequence diagram for preserving unread counts during messaging-history.set import

sequenceDiagram
  actor User
  participant WhatsAppServer
  participant BaileysStartupService
  participant PrismaChat
  participant FindChatsApi

  User->>WhatsAppServer: Connect new instance
  WhatsAppServer-->>BaileysStartupService: messaging-history.set
  BaileysStartupService->>BaileysStartupService: Build chatsRaw entries
  BaileysStartupService->>BaileysStartupService: Set unreadMessages = chat.unreadCount ?? 0
  BaileysStartupService->>PrismaChat: [persist chatsRaw with unreadMessages]
  User->>FindChatsApi: findChats(instanceId)
  FindChatsApi->>PrismaChat: [read chats with unreadMessages]
  PrismaChat-->>FindChatsApi: chats including unreadMessages
  FindChatsApi-->>User: chats with correct unreadCount

Loading

File-Level Changes

Change	Details	Files
Propagate unread counts from Baileys messaging-history.set chat records into the chat.unreadMessages persistence layer.	Extend the chatsRaw type to include an optional unreadMessages numeric field. Populate unreadMessages in chatsRaw.push(...) using chat.unreadCount ?? 0 so history-synced chats persist accurate unread counts instead of defaulting to zero.	src/api/integrations/channel/whatsapp/whatsapp.baileys.service.ts

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've left some high level feedback:

• The inline chatsRaw type is starting to diverge from other chat upsert logic (e.g. the handler that already maps unreadMessages); consider extracting a shared type/interface for these raw chat objects so future changes (like adding fields) stay in sync across the different insert/update paths.
• By forcing unreadMessages: chat.unreadCount ?? 0 you override any DB-level default; if the intent is to distinguish between "server explicitly said 0" and "no unread count provided", you might want to pass undefined when chat.unreadCount is undefined and let the existing schema/defaults handle that case.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The inline `chatsRaw` type is starting to diverge from other chat upsert logic (e.g. the handler that already maps `unreadMessages`); consider extracting a shared type/interface for these raw chat objects so future changes (like adding fields) stay in sync across the different insert/update paths.
- By forcing `unreadMessages: chat.unreadCount ?? 0` you override any DB-level default; if the intent is to distinguish between "server explicitly said 0" and "no unread count provided", you might want to pass `undefined` when `chat.unreadCount` is `undefined` and let the existing schema/defaults handle that case.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[zcag]

Pushed a commit addressing both points, thanks!

[zcag]

Thanks @sourcery-ai — both points are already addressed in the current diff:

1. Shared type: extracted a ChatRaw type and applied it to both raw-chat paths — chatsToInsert: ChatRaw[] (the CHATS_UPSERT path) and chatsRaw: (ChatRaw & { remoteLid: string })[] (the messaging-history.set path) — so adding fields later stays in sync across both insert paths.

2. DB default vs. forced 0: the code passes unreadMessages: chat.unreadCount directly rather than ?? 0, so when the server doesn't send a count we pass undefined and let the Prisma column default handle it — preserving the "server explicitly said 0" vs "no value provided" distinction you flagged. I also aligned the existing CHATS_UPSERT path to the same form (dropping its prior !== undefined ? … : 0) so both paths behave identically.

The PR description has been updated to match — it previously described a ?? 0 approach that the code doesn't actually take.