[NOWEB] poll.vote webhook events dropped (>95% loss)

[omernesh]

Describe the bug

The poll.vote webhook event is documented in the OpenAPI spec (PollVote / PollVotePayload schemas), but on the NOWEB engine the vast majority of poll vote events are never delivered to the webhook. Polls can be created and votes can be cast successfully, but the corresponding poll.vote webhook events are rarely (if ever) fired.

Version

{
  "version": "2026.4.2",
  "engine": "NOWEB",
  "tier": "PLUS"
}

Steps

To Reproduce:

1. Start a NOWEB session and configure a webhook URL
2. Subscribe to poll.vote events
3. Create a poll via POST /api/sendPoll:

{
  "chatId": "1234567890@c.us",
  "session": "default",
  "poll": {
    "name": "Test poll",
    "options": ["Option A", "Option B", "Option C"],
    "multipleAnswers": false
  }
}

4. Cast votes from one or more participants
5. Observe that the webhook receives no (or extremely few) poll.vote events

Expected behavior

Each vote on a poll should trigger a poll.vote webhook event with the voter and selected option(s).

Requests - Responses

The poll creation works fine and returns a valid message. Votes are visible in the WhatsApp UI. However, the webhook endpoint receives no poll.vote events — confirmed by checking webhook server logs over multiple polls and dozens of votes.

Additional context

• This appears to be NOWEB-specific — the underlying WhatsApp Web socket may not reliably emit poll vote decryption events
• This makes it impossible to build poll-based workflows (surveys, voting bots, etc.) on the NOWEB engine
• poll event (poll creation) works correctly; only poll.vote (vote cast) is affected

[devlikepro]

Could you please check if there are any error logs or poll.vote.failed events related to this?

[omernesh]

+1 — and a broader ask in the same area: beyond the dropped poll.vote events, NOWEB currently gives us no way to reconstruct full poll state. Two things are missing for us: (a) which participant voted for which option, and (b) the aggregate vote count per option. For any poll-driven workflow both are essential. Would love to see full poll support on NOWEB — reliable poll.vote delivery with voter identity and per-option tallies. Thanks!

[omernesh]

Following up on my earlier report with fresh measured data (NOWEB, 2026.7.1) — the picture is both better and more specific than the ">95% loss" in the title, and we can now name the exact remaining bug.

What works today (measured, not guessed): across our recent live polls, poll.vote webhooks arrived reliably and carried the voter JID and the plaintext selected option text (Unicode/emoji included) — so NOWEB is decrypting and resolving votes server-side correctly in the common case. Decrypt failures were the exception, and they arrive tagged (poll.vote.failed), not silently dropped. Whatever was causing the original >95% loss appears resolved in current builds for steady-state sessions.

The remaining bug — session restart wipes the poll-creation store, permanently breaking decrypt for older polls. Reproducible signature from our data:

• Two independent voters, voting on the same poll, a full day apart — both produced poll.vote.failed.
• The poll was several days old; the failures were isolated to the one session that had been restarted since the poll was created.
• Meanwhile a different, un-restarted session decrypted votes on same-age polls with zero failures.

That pattern rules out poll age and per-vote flakiness: vote decryption requires the poll-creation record (encKey + option list), that record lives in the engine's local store, and a NOWEB session restart/reconnect does not restore historical poll-creation records — so every subsequent vote on a pre-restart poll fails decryption permanently for that session.

Suggested fix direction: persist poll-creation records (message key, encKey, options) in the session store so they survive restart/reconnect — analogous to how chats/contacts survive. Even a bounded retention (e.g. polls from the last N days) would eliminate the failure mode for practical usage, since WhatsApp polls are short-lived.

(Application-side we now snapshot each poll's definition at creation time so our own reads don't depend on the volatile store — but the vote decryption itself can only happen engine-side, so restarts still lose old-poll votes until this is addressed.)