[GOWS] getChatMessages returns empty/422 for groups with recent activity

[Seithx]

Describe the bug

GET /api/{session}/chats/{chatId}/messages returns 422 Unprocessable Entity or empty results for group chats that have recent activity. This makes catch-up after a session reconnect unreliable -- messages received while the session was down are lost.

The session status reports WORKING, webhooks for new messages work fine, but fetching recent history for the same chat fails.

Version

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

Steps to reproduce

1. Session is WORKING, a group receives messages via webhook normally
2. Session goes STOPPED (or container restarts)
3. Session recovers to WORKING
4. Call GET /api/default/chats/{groupJid}/messages?limit=50
5. Response: 422 Unprocessable Entity with body:

{
  "error": "Session status is not as expected. Try again later or restart the session",
  "session": "default",
  "status": "STOPPED",
  "expected": ["WORKING"]
}

6. Even after session is confirmed WORKING again, the same endpoint returns empty or 422 for several groups

Observed behavior

• Out of 18 monitored groups, 11 consistently fail with 422 on getChatMessages after a session restart
• Retry 30 seconds later: same 422
• The groups that fail are the same every time
• Webhooks for these same groups work immediately after session recovery
• This makes post-downtime catch-up impossible for affected groups

Expected behavior

getChatMessages should return recent messages for any group the session is a member of, especially after session recovery.

Docker Logs

WARNING: failed to fetch from <groupJid>: Client error '422 Unprocessable Entity'
WARNING: Forward catch-up: failed to fetch from <groupJid>: Client error '422 Unprocessable Entity'
WARNING: Forward catch-up retry: still failing for <groupJid>
INFO: Forward catch-up: no missed messages from <groupJid>

Additional context

• Affects CORE tier (GOWS engine) -- cannot verify if Plus/PRO behave differently
• The 422 response references "status": "STOPPED" even when /api/sessions/default returns WORKING
• Possibly a race condition where the chat list hasn't fully synced after session restart, but the session status already reports WORKING
• Related: /api/{session}/chats/{chatId}/messages - fails for the chatId which have not sent us a message recently #163 (similar issue on WEBJS engine), [WEBJS] - 500 error when pulling old WhatsApp messages for a specific date range #1805, [WEBJS] - Failed to fetch old whatsapp message #1885

[Seithx]

Additional finding — tested ~20 min after session recovery:

Result	Groups
Returned messages (1-3)	5 / 18
200 OK but 0 messages	7 / 18
Still failing (422/timeout)	6 / 18

Even 20 minutes after session reports WORKING, only 5 out of 18 monitored groups return messages via getChatMessages. The rest either return empty or still fail. Webhooks for all 18 groups work fine during this same period.

[Seithx]

Finding: limit parameter affects success rate + workaround

Tested getChatMessages with limit=1 vs limit=50 across 19 monitored groups on a stable session (WORKING for 1h+, no recent restart). Tested twice (March 22 and March 26) with consistent results.

Pattern	limit=1	limit=50	Groups
Both work	200 OK	200 OK	6
Small works, large timeouts	200 OK	Timeout 30s	6
Both timeout	Timeout 30s	Timeout 30s	5-6

Key insight: 6 groups succeed with limit=1 but timeout with limit=50. This points to a performance/pagination issue in GOWS message retrieval, not a sync or auth problem.

Consistently failing groups (both tests, both limits, always timeout): 6 groups that never respond to getChatMessages regardless of limit size. Webhooks work perfectly for all of them. Group names cached via /chats endpoint resolve fine -- only getChatMessages is broken.

Workaround: Graduated retry

We implemented a fallback chain in our catch-up logic:

1. Try limit=50 with 15s timeout
2. If timeout, retry limit=10 with 15s timeout
3. If still timeout, retry limit=1 with 10s timeout

Result from logs:

Catch-up: 120363141340651895@g.us succeeded with limit=1 (fallback)

This recovers the "middle" group (pattern 2) but not the permanently failing ones (pattern 3).

Environment

WAHA GOWS engine 2026.3.2 | CORE tier | Docker linux/amd64

[Seithx]

Update: Root cause theory + WAHA 2026.3.4

After further investigation, the permanently failing groups (pattern 3 from my previous comment) align with reports in #1765 and #793 -- the underlying whatsmeow local SQLite store doesn't sync message history for certain groups. The GOWS engine queries this local store for getChatMessages, but webhooks bypass it entirely (they come from the live connection), which explains why webhooks always work but history fetch fails.

New version note

WAHA 2026.3.4 introduces WAHA_GOWS_DEVICE_* env vars for controlling historical sync depth. This may fix the permanently failing groups by forcing a deeper initial sync. Planning to test after a 7-day safety delay (auto-upgrade scheduled).

Current workaround status

The graduated retry (limit=50 -> limit=10 -> limit=1) has been stable in production for 2+ weeks. It recovers 6 additional groups (the "middle" pattern) consistently. The 6 permanently failing groups remain webhook-only.

Environment

WAHA GOWS 2026.3.2 | CORE tier | Docker linux/amd64

[Seithx]

Additional symptom: group missing from /api/{session}/groups but webhooks work

Related to the same root cause (GOWS local SQLite not fully synced).

Observed (WAHA 2026.3.2, GOWS, CORE):

• Group 972529551592-1619675097@g.us (active, user is a member, ~268 participants)
• GET /api/default/groups returns 264 groups -- this group is not listed
• Webhooks from this group arrive normally (messages stored successfully)
• GET /api/default/chats/{groupJid}/messages also fails (timeout/empty)

Impact: Any logic that depends on the /groups endpoint (e.g. validating forwarding rules, building group name cache) silently misses these groups. The disconnect between "webhooks work" and "API doesn't see the group" is confusing.

This appears to be the same underlying issue: GOWS whatsmeow local store doesn't have complete group metadata for all groups the phone is a member of. Related: #1765, #793.

Question: Would WAHA_GOWS_DEVICE_* env vars in 2026.3.4+ help with this specific symptom?