mautrix-whatsapp does not persist group participants
While planning a fix to a recipient-visibility bug in a matrix bridge consumer, verified the proposed approach against the actual bridge database schema and discovered the fix would not work as described — leading to a different fix using a bridge admin command instead.
For mautrix-whatsapp (and likely other whatsmeow-based bridges), the bridge's SQLite does NOT persist the participant list of WhatsApp groups. The portal table's metadata JSONB for a group room contains only last_sync and addressing_mode — no members array, no participants table. whatsmeow (the underlying Go library) fetches participants on demand from WhatsApp servers via GetGroupInfo with an in-memory getCachedGroupData. So a consumer that wants authoritative group membership cannot just read the bridge's database — the data isn't there. The actual ways to get it: (a) trigger the bridge's !wa sync groups admin command from your matrix client, which causes the bridge to fetch from WhatsApp and re-join missing ghosts to the matrix room (your /sync then sees member events); (b) call the bridge's provisioning HTTP API if enabled; (c) implement your own whatsmeow session, which is far more work and conflicts with the bridge's session. Same caution likely applies to mautrix-telegram, mautrix-discord — verify the schema before assuming the bridge persists what you need.
Before proposing a fix that reads upstream state from a bridge's database, dump the relevant table schema and confirm the column actually exists. The bridge often holds a far thinner view than its upstream protocol suggests, with on-demand fetches papering over the gap at runtime.