fix(whatsapp): forward quotedMessageId/context to agent prompt - #28878
fix(whatsapp): forward quotedMessageId/context to agent prompt#28878Shizoqua wants to merge 1 commit into
Conversation
The WhatsApp bridge (PR NousResearch#25489) already extracts quotedMessageId, quotedParticipant, quotedRemoteJid, and hasQuotedMessage from Baileys' contextInfo, but the adapter in gateway/platforms/whatsapp.py only used quotedParticipant for admission control. The remaining fields were dropped, so reply-based corrections in WhatsApp lost all context — the agent only saw the new reply text with no reference to the quoted message. This forwards the quoted-message context to the agent using the same shape as the Matrix adapter (see NousResearch#27946 fix), keeping cross-platform behavior consistent. Non-reply messages are unchanged. Fixes NousResearch#28823
teknium1
left a comment
There was a problem hiding this comment.
Thanks for taking this on. The underlying bug is real on current main, but this patch only carries the quoted message id; the gateway prompt path still needs quoted text before the agent sees useful reply context.
Problems
gateway/platforms/whatsapp.py:1166-1174on current main drops quoted metadata when constructingMessageEvent, so the premise is valid.gateway/run.py:8048-8056only injects reply context into the prompt when bothevent.reply_to_textandevent.reply_to_message_idare set.- This PR's new test at
tests/gateway/test_whatsapp_formatting.py:350-351verifiesreply_to_message_id == "ABC123"whilereply_to_text is None, so the existing prompt injection guard would still skip the[Replying to: ...]prefix.
Suggested changes
- Have
scripts/whatsapp-bridge/bridge.jsextract aquotedTextvalue from BaileyscontextInfo.quotedMessageand include it in the bridge payload. - Map that field to
MessageEvent.reply_to_textingateway/platforms/whatsapp.py. - Add a regression that runs through
GatewayRunner._prepare_inbound_message_textand proves WhatsApp replies produce the visible[Replying to: "..."]prompt prefix.
Automated hermes-sweeper review.
| message_id=data.get("messageId"), | ||
| media_urls=cached_urls, | ||
| media_types=media_types, | ||
| reply_to_message_id=reply_to_message_id, |
There was a problem hiding this comment.
Setting only reply_to_message_id does not make the quoted context visible to the agent: gateway/run.py injects the reply prefix only when reply_to_text is also present. This needs the bridge to send quoted text and the adapter to populate MessageEvent.reply_to_text as well.
|
|
||
| assert event is not None | ||
| assert event.reply_to_message_id == "ABC123" | ||
| assert event.reply_to_text is None # bridge doesn't emit quoted text yet |
There was a problem hiding this comment.
This assertion locks in the incomplete behavior. A regression for the reported bug should prove the quoted body reaches the prompt, e.g. by feeding the event through _prepare_inbound_message_text and checking for the [Replying to: "..."] prefix.
|
Implemented on current main. This is an automated hermes-sweeper review.
This also resolves the missing-quoted-text concern raised in the prior review and the adapter gap documented in #28823. |
The WhatsApp bridge (PR #25489) already extracts quotedMessageId, quotedParticipant, quotedRemoteJid, and hasQuotedMessage from Baileys' contextInfo, but the adapter in gateway/platforms/whatsapp.py only used quotedParticipant for admission control. The remaining fields were dropped, so reply-based corrections in WhatsApp lost all context — the agent only saw the new reply text with no reference to the quoted message.
This forwards the quoted-message context to the agent using the same shape as the Matrix adapter (see #27946 fix), keeping cross-platform behavior consistent. Non-reply messages are unchanged.
Fixes #28823