#1232·whatsmeow

SetGroupAnnounce and SetGroupMemberAddMode return 400 on community JIDs

Author: neoandCreated Aug 22, 2026Updated Aug 22, 2026

Summary

SetGroupAnnounce and SetGroupMemberAddMode return info query returned status 400: bad-request when called on community JIDs (both parent with IsParent=true and default sub-group with IsDefaultSubGroup=true).

The same library functions work correctly on regular group JIDs. The IQ namespace is the same (w:g2), but the tag differs between working and failing operations.

Environment

  • whatsmeow: v0.0.0-20260805124304-6723e556f35a (latest available locally)
  • WhatsApp: production (api.neoai.systems, prod build neogo:20260822114823)
  • Instance: regular group owner + community creator

Reproduction

  1. Create a community via CreateGroup{IsParent: true} → returns community parent JID (e.g. [email protected], IsParent: true) and a default sub-group (e.g. [email protected], IsDefaultSubGroup: true).
  2. Call SetGroupAnnounce(ctx, parentJID, true) → returns info query returned status 400: bad-request.
  3. Call SetGroupAnnounce(ctx, defaultSubGroupJID, true) → returns same error.
  4. Call SetGroupName(ctx, parentJID, "new name")works (200 OK, emits group.subject_changed).
  5. Call SetGroupDescription(ctx, parentJID, "new description")works.

Same w:g2 IQ, different tag — WhatsApp accepts <subject>/<description> and rejects <announcement>/<member_add_mode> on community JIDs.

Same-Instance Comparison

GetGroupInfo(communityJID)              → works
GetSubGroups(communityJID)              → 403 forbidden (sub-groups of own community)
SetGroupName(communityJID, ...)         → works
SetGroupDescription(communityJID, ...)  → works
SetGroupAnnounce(communityJID, true)    → 400 bad-request
SetGroupMemberAddMode(communityJID,..) → 400 bad-request

What I've ruled out

  • Not a permission issue — the calling account created the community (OwnerJID matches) and is the only participant.
  • Not a JID format issue — same error on community parent JID (IsParent=true) and default sub-group JID (IsDefaultSubGroup=true); both are well-formed @g.us JIDs.
  • Not a stale cache issueGetGroupInfo works in the same session for the same JID; the error is specific to the mutation IQ.
  • Not a bug in our wrapper — same call goes through sendGroupIQ(ctx, iqSet, jid, waBinary.Node{Tag: "announcement"}) that works on regular groups.
  • Not fixed in upstream — checked local cache up to 20260805; SetGroupAnnounce source is identical across versions.

Hypothesis

WhatsApp changed the protocol for community-level mutations. The w:g2 namespace + <announcement> tag is rejected for community JIDs. Likely either:

  1. Community mutations need a different namespace (e.g. w:community or similar)
  2. Community mutations need additional context in the IQ (e.g. linked_parent attribute)
  3. The mutation must be applied to a specific sub-group, not the parent or default sub-group

SetGroupName and SetGroupDescription work, so whatever the new protocol is, it's not "no mutations allowed on community JIDs" — it's tag-specific.

Suggested fix

A community-aware SetGroupAnnounce (or a SetCommunityAnnounce variant) that:

  • Detects IsParent=true from prior GetGroupInfo and either routes the mutation to the correct sub-group or uses a different IQ format.

Logs

ERROR SetGroupAnnounce failed: info query returned status 400: bad-request
POST /api/v1/community/announce
handler error code=502 stable_code=internal_error message="whatsmeow error" err="info query returned status 400: bad-request"

The IQError.RawNode and IQError.ErrorNode would have more detail but are not surfaced in our logs — happy to add diagnostic capture if helpful for triage.

Impact

  • Affects: NeoGo story 36-1 (Community Management API) — FR1 SetGroupAnnounce and FR5 SetMemberAddMode cannot be validated against communities until fixed.
  • Workaround: temporary — return a clearer error (501 Not Implemented) when JID is community-linked; for now, our callers get a 500 with a generic whatsmeow error.

Thanks!