- Move config from messages.ackReaction to whatsapp.ackReaction
- New structure: {emoji, direct, group} with granular control
- Support per-account overrides in whatsapp.accounts.*.ackReaction
- Add Zod schema validation for new config
- Maintain backward compatibility with old messages.ackReaction format
- Update tests to new config structure (14 tests, all passing)
- Add comprehensive documentation in docs/providers/whatsapp.md
- Timing: reactions sent immediately upon message receipt (before bot reply)
Breaking changes:
- Config moved from messages.ackReaction to whatsapp.ackReaction
- Scope values changed: 'all'/'direct'/'group-all'/'group-mentions'
→ direct: boolean + group: 'always'/'mentions'/'never'
- Old config still supported via fallback for smooth migration
- Fix bug where ack reaction was not sent when group activation is 'always'
- When requireMention=false (activation: always), always send reaction
- Add test case for activation='always' scenario
- Update inline comments for clarity
- Add automatic emoji reactions on inbound WhatsApp messages
- Support all ackReactionScope modes: all, direct, group-all, group-mentions
- Reaction is sent AFTER successful reply (unlike Telegram/Discord)
- Errors are logged with proper context
- Add comprehensive test suite for ack reaction logic
Config usage:
messages:
ackReaction: "👀"
ackReactionScope: "group-mentions" # default
Closes: WhatsApp ack-reaction feature request
WhatsApp group mentions using the new Linked ID format (@lid) were not
being detected because jidToE164() was called without the authDir needed
to find the LID reverse mapping files.
Now isBotMentioned() and debugMention() accept an optional authDir
parameter, which is passed through from account.authDir.
Error messages in sendMessageWhatsApp, sendReactionWhatsApp, and
sendPollWhatsApp included hardcoded \"WhatsApp\" references. This caused
confusion when cron jobs using other providers (e.g., Telegram) failed
with errors mentioning WhatsApp.
Changes error messages to be provider-agnostic while maintaining the
same error handling behavior.
Fixes#461Fixes#470
Co-Authored-By: Claude <noreply@anthropic.com>
Enables multiple agents to process the same message simultaneously,
allowing teams of specialized agents with atomic tasks to work together
in the same group using one phone number.
Key features:
- Configure multiple agents per WhatsApp group/DM via routing.broadcast
- Parallel (default) or sequential processing strategies
- Full session isolation (separate history, workspace, tools per agent)
- Minimal code changes (~50 lines in auto-reply.ts)
- Backward compatible with existing routing
Use cases:
- Specialized agent teams (code reviewer + security scanner + docs)
- Multi-language support (EN + DE + ES agents)
- Quality assurance workflows (support + QA agents)
- Task automation (tracker + logger + reporter)
Example config:
{
"routing": {
"broadcast": {
"strategy": "parallel",
"120363403215116621@g.us": ["alfred", "baerbel", "assistant3"]
}
}
}
This enables scaling to hundreds of focused micro-agents on a single
phone number, each handling specific atomic tasks.
Recent changes added recordProviderActivity calls with accountId, but
the type definition and usage didn't include accountId in ActiveWebSendOptions.
This fix adds the optional accountId field and uses optional chaining
when accessing it to handle cases where options is undefined.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
