[BUG] Chat table not creating new entries since late September 2025 - @lid format contacts affected

[linefds]

📋 Bug Description

## Description
The Evolution API stopped creating new entries in the `Chat` table after late September 2025. Messages continue to be saved normally in the `Message` table, but corresponding chat records are not being created, resulting in "orphaned" messages.

## Environment
- **Evolution API Version:** 2.3.4 (issue existed before update from previous version)
- **Database:** PostgreSQL

## Current Behavior
1. New messages are being saved to the `Message` table ✅
2. Existing chats in the `Chat` table continue to be updated ✅
3. New chat entries are NOT being created in the `Chat` table ❌

### Evidence
**Last chat creation date:**
```sql
SELECT MAX("createdAt") as last_chat_created
FROM "Chat"
WHERE "instanceId" = '<your-instance-id>';
-- Result: 2025-09-25T15:33:34.064Z

Orphaned chats (messages without corresponding Chat entry):

SELECT COUNT(DISTINCT m.key->>'remoteJid') as orphaned_chats
FROM "Message" m
LEFT JOIN "Chat" c ON m.key->>'remoteJid' = c."remoteJid" 
  AND m."instanceId" = c."instanceId"
WHERE 
  m."instanceId" = '<your-instance-id>'
  AND c.id IS NULL
  AND m.key->>'remoteJid' NOT LIKE '%@g.us';
-- Result: 26 orphaned chats

Breakdown by contact format:

SELECT 
  CASE 
    WHEN m.key->>'remoteJid' LIKE '%@lid' THEN 'LID (new format)'
    WHEN m.key->>'remoteJid' LIKE '%@s.whatsapp.net' THEN 'WhatsApp standard'
    ELSE 'Other'
  END as jid_type,
  COUNT(DISTINCT m.key->>'remoteJid') as orphaned_chats,
  MIN(TO_TIMESTAMP(m."messageTimestamp")) as first_message,
  MAX(TO_TIMESTAMP(m."messageTimestamp")) as last_message
FROM "Message" m
LEFT JOIN "Chat" c ON m.key->>'remoteJid' = c."remoteJid" 
  AND m."instanceId" = c."instanceId"
WHERE 
  m."instanceId" = '<your-instance-id>'
  AND c.id IS NULL
  AND m.key->>'remoteJid' NOT LIKE '%@g.us'
GROUP BY jid_type;

Results:

• 16 chats with @lid format (WhatsApp's new privacy format) - first appeared September 30, 2025
• 10 chats with @s.whatsapp.net format (traditional)

Possible Root Cause

The issue appears to coincide with WhatsApp's rollout of the @lid format for contact privacy. The API may not be handling this new format when creating Chat table entries, though traditional @s.whatsapp.net contacts are also affected.

Workaround

Currently using a SQL query that unions both Chat table entries and orphaned chats derived from the Message table:

WITH chats_orfaos AS (
  SELECT DISTINCT
    m.key->>'remoteJid' as "remoteJid",
    NULL as id,
    NULL as name,
    0 as "unreadMessages"
  FROM "Message" m
  LEFT JOIN "Chat" c ON m.key->>'remoteJid' = c."remoteJid" 
    AND m."instanceId" = c."instanceId"
  WHERE 
    m."instanceId" = '<your-instance-id>'
    AND c.id IS NULL
    AND m.key->>'remoteJid' NOT LIKE '%@g.us'
)
SELECT * FROM "Chat" WHERE "instanceId" = '<your-instance-id>'
UNION ALL
SELECT * FROM chats_orfaos;

🔄 Steps to Reproduce

1. Start a new conversation with a contact that has never messaged the instance before
2. Send/receive messages (messages are saved to Message table correctly)
3. Query the Chat table for the new contact's remoteJid
4. The chat entry is missing despite messages being present in Message table

✅ Expected Behavior

New conversations should automatically create corresponding entries in the Chat table when the first message is received or sent, regardless of the remoteJid format (@lid or @s.whatsapp.net).

❌ Actual Behavior

• Chat management features relying on the Chat table don't work for new contacts
• Automation workflows (like auto-archiving inactive chats) miss these conversations
• Data inconsistency between Message and Chat tables
• Analytics and reporting based on the Chat table are incomplete

🌍 Environment

• OS: [e.g. Ubuntu 20.04, Windows 10, macOS 12.0]
• Node.js version: [e.g. 18.17.0]
• Evolution API version: [e.g. 2.3.4]
• Database: [e.g. PostgreSQL 14, MySQL 8.0]
• Connection type: [e.g. Baileys, WhatsApp Business API]

📋 Logs

📝 Additional Context

• Messages continue to be delivered and received normally
• The Contact table continues to be updated correctly (last update: current date)
• Only the Chat table creation is affected (existing chats continue to update)
• Updating to version 2.3.4 did not resolve the issue
• The problem affects approximately 0.4% of total chats but impacts all new conversations

[luizcw]

UP

[juliancesar]

UP

[jonathanpog98]

UP