A caller could tag participants on send-text and the media sends, but the
same array was rejected with "property mentions should not exist" on the
routes that carry text just as plainly: reply, edit, send-template and the
bulk items. The engines can carry the tags on all of them, so the field was
missing from the DTOs rather than from the engines.
- replyToMessage and editMessage take an optional mentions list, forwarded
by both adapters. Baileys spreads the existing withMentions helper into
the content; whatsapp-web.js passes the options bag its library already
accepts, and omits it entirely when no tags were asked for so an untagged
send keeps its previous call shape.
- send-template dispatches through sendText, so it also gained linkPreview.
quotedMessageId stays out: docs/06 publishes this route as one that
rejects it.
- Every bulk item type forwards its own list, audio included. Audio carries
no caption, but a mention still tags through contextInfo, which is why
the single-send audio route accepts it.
- An edit REPLACES the message content, so tags are re-applied rather than
preserved: a rewritten body loses the tags unless the list is sent again.
- The mentions caps and the 4096 text cap move to shared constants; the
effective limits are unchanged.
Verified: adapter, service and DTO tests per route, each with a negative
control; the DTO cases run through the real production validation pipe, so
they exercise the whitelist that produced the 400. Plugin rewrites of the
list are asserted on reply and edit, because message:sending is a
moderation chokepoint and reading the caller's own body there would send
the unredacted tags.
Yudhi Armyndharis
1437fa969f