[GOWS] - Labels read right after linking are wrong: labels removed from a chat are reported as still on it

[ahmadalmunajjed]

Describe the bug

Right after a session links, GET /api/{session}/labels/chats/{chatId} and GET /api/{session}/labels/{labelId}/chats report a chat as carrying labels that were removed from it before linking. The phone shows only the labels that are really on the chat.

Reproduced on 3 links out of 3. Which removed labels come back varies: one label was reported correctly on the second link and wrongly on the third. Labels changed while the session is linked are always right, and a live change to a label on that chat corrects it.

Version

{ "version": "2026.9.1", "engine": "GOWS", "tier": "CORE", "platform": "linux/x64" }

Steps

1. In the WhatsApp Business app, put a label on a chat, then remove it again. Keep another label on the chat.
2. Create a session and link the account (QR code or pairing code).
3. Wait for the app state sync to finish, then call GET /api/{session}/labels/chats/{chatId} with the chat's @lid ID.

Expected

Only the label that is on the chat.

Actual

The removed label is listed too. After the third link, two removed labels were listed.

• The engine store agrees with the API: gows_label_associations in gows.db holds a row for each wrongly reported label.
• Restarting the container does not change it. Nothing is replayed on a restart.

What the log shows

With WAHA_LOG_LEVEL=debug, the full sync at linking emits an events.LabelAssociationChat for every past change (FromFullSync: true), and they are not in chronological order. For one chat, in the order WAHA logged them (Timestamp of the change, Action.labeled):

label 13  12:11:14  labeled=true
label 13  12:11:58  labeled=false
label 14  12:24:28  labeled=true
label 12  08:02:17  labeled=true
label 13  08:11:53  labeled=true
label 13  08:25:46  labeled=false
label 14  12:26:46  labeled=false
label 13  12:08:27  labeled=true
label 13  12:10:33  labeled=false

The newest change for labels 13 and 14 is labeled=false, yet both end up stored as on the chat. Applying the events in the order above would also leave both off, so the order in which they are stored seems to differ from the order in which they are logged.

A events.LabelEdit with deleted: true for a label also arrived before the LabelEdit that created it.

Workaround

Subscribing the webhook to engine.event and taking, per label and chat, the change with the newest Timestamp gives the phone's real state.

Possibly related

#1875