[GOWS][Chatwoot] - 2026.8.1 maps mirrored fromMe messages to the wrong contact/conversation

[WilkoMarketing]

Describe the bug

After upgrading WAHA GOWS from 2026.7.1 to 2026.8.1, outgoing messages sent directly from the linked WhatsApp mobile/desktop client to different 1:1 contacts were mirrored into Chatwoot under the same incorrect contact/conversation.

Incoming replies continued to arrive under their own contact conversations. WhatsApp itself displayed the recipients and history correctly; the incorrect association occurred in the WAHA-to-Chatwoot synchronization.

This affected an existing production integration that had been working correctly on 2026.7.1. The impact was immediate on ongoing conversations and created a data-integrity/privacy risk, so we could not keep 2026.8.1 deployed. We had to perform an emergency rollback to 2026.7.1. Without changing configuration or session data, the rollback restored correct conversation routing.

Version

{
  "version": "2026.8.1",
  "engine": "GOWS",
  "tier": "CORE"
}

• Regressing image: devlikeapro/waha:gows-2026.8.1
• Regressing manifest: sha256:853dfeda32bb46f07423b61e562b164b503f242d3fa21aeb8e67e2c42b2087d5
• Known-good image after rollback: devlikeapro/waha:gows-2026.7.1
• Known-good manifest: sha256:8f3a7b11310594b973a588b2f7de061864c83532ae2cdff43280db0402bead29
• Deployment: Docker Swarm
• Chatwoot-compatible application: v4.20.0
• Existing authenticated session and persistent volumes were preserved.

Steps to reproduce

1. Run an authenticated GOWS session on 2026.7.1 with the Chatwoot integration enabled.
2. Upgrade only the WAHA image to 2026.8.1, preserving configuration and session storage.
3. From the linked WhatsApp mobile/desktop client, send messages to two or more different 1:1 contacts.
4. Inspect the mirrored outgoing messages in Chatwoot.
5. Messages sent to different recipients appear under the same wrong contact/conversation.
6. Incoming replies may still appear under their correct separate conversations.
7. Roll back only the WAHA image to 2026.7.1 and repeat the test.

Expected behavior

Each mirrored outgoing fromMe message must be associated with the conversation for its actual remote recipient.

Actual behavior

On 2026.8.1, mirrored outgoing messages addressed to different recipients were associated with one conversation. Incoming messages remained associated with separate contact conversations.

Requests - Responses

The issue occurred through the built-in WAHA-to-Chatwoot integration, not a manually issued API request. WAHA remained authenticated and webhook requests continued returning HTTP 200.

Docker Logs

No HTTP 4xx/5xx, authentication, startup, fatal, or panic errors were observed.

Sanitized correlation evidence:

• Chatwoot contained distinct contacts, contact-inbox rows, conversations, and source identifiers; the contacts were not merged in the Chatwoot database.
• On 2026.8.1, 58 consecutive mirrored outgoing records were assigned to one conversation although messages had been sent to multiple recipients.
• The records were outgoing AgentBot messages, consistent with WAHA mirroring messages sent from the linked WhatsApp client.
• After rollback to 2026.7.1, a controlled test produced seven mirrored outgoing records distributed across two distinct conversations, and both displayed correctly.
• Post-rollback checks showed all services running, authenticated sessions, successful webhooks, and no transport/startup/authentication errors.

Raw logs and payloads are omitted because they contain customer data. Additional sanitized metadata can be provided if maintainers specify the exact fields required.

Screenshots

Not attached because the available captures contain customer identities and message content. The behavior was confirmed in the UI and through anonymized database correlation.

Additional context

The timing and behavior suggest a regression in GOWS JID/LID resolution for fromMe messages mirrored into Chatwoot. Release 2026.8.1 changed Chatwoot/GOWS LID-to-phone and WhatsApp JID population behavior.

Related:

• https://github.com/devlikeapro/waha/releases/tag/2026.8.1
• [NOWEB] - version 2025.9.x ~ 2025.11.1 Webhook payload.from sometimes contains @lid instead of a valid WhatsApp number — causing contact data corruption #1608

Current workaround: remain pinned to devlikeapro/waha:gows-2026.7.1. The rollback stopped new misrouting, but already misplaced Chatwoot history was not automatically repaired.

No raw payloads, message content, phone numbers, contact names, company names, hostnames, credentials, or internal account/inbox/conversation identifiers are included.

[devlikepro]

2026.8.2 - GOWS - fromMe messages mirrored to the wrong contact/conversation - #2241

[WilkoMarketing]

Please reopen #2241: the same user-visible routing failure occurs with GOWS 2026.8.2 in our existing Chatwoot-compatible integration.

We upgraded from 2026.7.1 to 2026.8.2 on September 10 after the release notes declared this fixed. On September 16 a user reported native WhatsApp outgoing messages to different recipients appearing in one incorrect conversation, while incoming replies appeared separately.

Read-only database checks show the problem is not confined to the reporting account. For mirrored outgoing AgentBot messages during comparable six-day windows before/after the deployment:

Anonymized inbox	Before: messages / distinct conversations	After: messages / distinct conversations	After: messages assigned to own-number contact
A	472 / 87	555 / 1	555
B	117 / 15	98 / 1	98
C	2 / 2	3 / 1	3

Inbox C has too little traffic to establish misrouting independently. Inbox B shows a strong matching pattern, although we have not received user confirmation from that account. For inbox A, the screenshots and user report corroborate the database evidence.

Affected image: devlikeapro/waha:gows-2026.8.2@sha256:23f2d002d262b54c711af02b5fe79b1948bbf31e6b64cf7776cd6bd2f7477b47
Consumer: a Chatwoot-compatible fork v4.20.0 using its native WAHA webhook handler. Clarification to our original report: this is the consumer's native webhook integration; we have not established that the WAHA built-in Chatwoot App itself is involved.

We have not yet isolated whether the remaining defect lies in GOWS event identity fields, the consumer's normalization, or their interaction. The incorrect stored associations and their correlation with the update are confirmed.

Because existing production conversations were affected, we had to roll back again through our existing Portainer stack to devlikeapro/waha:gows-2026.7.1@sha256:8f3a7b11310594b973a588b2f7de061864c83532ae2cdff43280db0402bead29, preserving configuration and session storage. Rollback completed September 16 at 16:40:43 UTC. Services are healthy, sessions authenticated, and webhooks returned HTTP 200.

Functional two-contact routing validation after this second rollback is pending; we are not claiming functional recovery yet. Existing misplaced history has not been modified.

Could you reopen this issue and clarify the expected recipient-side identity fields for native-client fromMe events in GOWS 2026.8.2? We can provide synthetic/anonymized field relationships if you specify the fields required. No customer names, message content, phone numbers, hosts, credentials, or internal account identifiers are included.