hermes - 💡(How to fix) Fix [Bug]: WhatsApp messages stuck at 1 tick — delivery ACK missing in addition to read receipts

Describe the bug

After deploying Hermes v0.14.0 (v2026.5.16) with the native WhatsApp platform (Baileys bridge on :3001), incoming WhatsApp messages stay at 1 tick on the sender's side — i.e., neither the delivery ACK (2nd grey tick) nor the read receipt (blue ticks) is being sent back to WhatsApp servers.

The agent receives and processes the message correctly and sends a reply that arrives normally. The sender just never sees their original message marked as delivered, let alone read.

This is a worse variant of #6055 and the missing receipt described in #6539: those report missing read receipts but confirm 2 grey ticks work. In our case delivery itself is not being acknowledged back.

To Reproduce

1. Deploy Hermes v0.14.0 with the native WhatsApp platform (Baileys via extra.bridge_port).
2. Pair via hermes whatsapp pair (creds stored in $HERMES_HOME/credentials/whatsapp/default/).
3. Send any DM message from an allowlisted phone to the linked number.
4. Observe:
   • Sender sees: 1 grey tick only (never advances to 2 grey or blue).
   • Hermes side: message is received, hooks fire (agent:start), LLM is invoked, reply is sent and arrives at the sender.

Expected behavior

Baileys should automatically emit a delivery receipt to WhatsApp servers as soon as the message arrives at the bridge — sender should see 2 grey ticks. Then sock.readMessages([key]) should be called after the gateway accepts the message — sender should see blue ticks.

Environment

• Hermes Agent: v0.14.0 (v2026.5.16) — Latest at the time of report (2026-05-16)
• Platform: WhatsApp native (Baileys bridge, not SendBlue)
• Config (relevant excerpt):

  platforms:
    whatsapp:
      enabled: true
      reply_prefix: ""
      extra:
        bridge_port: 3001
        session_path: /opt/data/credentials/whatsapp/default

• Docker base: python:3.11-bookworm + Node 22 + Playwright
• Deployment: Railway, single container per broker

Additional context

• Boot logs show clean bridge connect: [Whatsapp] Bridge ready (status: connected) and [Whatsapp] Bridge started on port 3001.
• [hooks] Loaded hook 'whatsapp-gate' for events: ['agent:start'] — custom pre-LLM access gate (via gateway-pre-llm-veto.patch); deny path not triggering here (user is allowlisted).
• Session was preserved across the v0.13.0 → v0.14.0 upgrade (no re-pairing).
• Same symptom previously observed in v0.13.0 — upgrade did not change behavior.

Related issues

• #6055 — WhatsApp read receipts not sent back to WhatsApp servers (P2)
• #6539 — feat(whatsapp): send read receipts (blue ticks) for processed messages

Both describe the missing read-receipt half. This issue adds: the prior step (delivery ACK / 2nd grey tick) is also missing, suggesting the bridge isn't emitting any receipt back to WA servers — not just readMessages.

Proposed direction

Likely fix is in scripts/whatsapp-bridge/bridge.js, after the inbound messages.upsert handler accepts the message:

// Acknowledge delivery (2nd grey tick) — should be emitted by Baileys
// automatically on message arrival; verify it's being called.
// Mark as read after gateway processes (blue ticks) — opt-in via env.
if (!msg.key.fromMe) {
  try {
    await sock.readMessages([msg.key]);
  } catch (err) {
    // non-fatal
  }
}

Happy to test a fix if a PR lands.