Bug: archiveChat fails with PrismaClientValidationError on v2.3.7

[onsfera]

Bug Description

POST /chat/archiveChat/{instanceName} always returns HTTP 500 with a PrismaClientValidationError.

Environment

• Evolution API version: 2.3.7
• Integration: WHATSAPP-BAILEYS
• Database: PostgreSQL 15

Steps to Reproduce

1. Connect a WhatsApp instance via Baileys
2. Send a message to a contact (so a chat exists)
3. Call POST /chat/archiveChat/{instanceName} with:

{
  "lastMessages": \[{
    "key": {
      "id": "3EB09C555B385CF03875A8",
      "fromMe": true,
      "remoteJid": "5519999999999@s.whatsapp.net"
    },
    "messageTimestamp": 1775243556
  }],
  "archive": true
}

4. Also tried: PUT method (returns 404), simplified payload {"chat":"...","archive":true}, and with/without lastMessages

Error Response

{
  "status": 500,
  "error": "Internal Server Error",
  "response": {
    "message": \[{
      "archived": false,
      "message": \[
        "An error occurred while archiving the chat. Open a calling.",
        "PrismaClientValidationError: Invalid `this.prismaRepository.contact.findMany()` invocation\\n\\nUnknown argument `remoteJid`. Available options are marked with ?"
      ]
    }]
  }
}

Root Cause Analysis

The archiveChat method calls G(o) (the JID normalizer), which internally calls whatsappNumber(). This function executes:

this.prismaRepository.contact.findMany({
  where: {
    instanceId: this.instanceId,
    remoteJid: { in: users.map(({ jid }) => jid) }
  }
})

The Contact Prisma model does not expose remoteJid as a direct filterable field in the where clause at line 275 of the compiled main.js. The error Unknown argument "remoteJid" confirms a schema mismatch.

Suggested Fix

In whatsapp.baileys.service.ts, the whatsappNumber method query should match the current Prisma schema for the Contact model. Either:

1. Ensure remoteJid is a direct scalar field on the Contact model (not nested in JSON)
2. Or update the query to use the correct field path if the schema changed

The archiveChat function itself is correct — it properly calls this.client.chatModify(). The bug is in the JID resolution path (G() → whatsappNumber() → contact.findMany()).

Impact

• archiveChat is completely broken on v2.3.7
• markChatUnread may also be affected (same code path)
• Any function routing through whatsappNumber() could hit this

Workaround

Archive only at the application level. The Baileys chatModify call is never reached.