Semantics of decrypt-fail="hide" and content-less SenderKeyDistributionMessage from rereg_recovery_request

[pedroivobraga]

Hi — a protocol-semantics question, plus an observation about how these end up on the events.Message path. Using whatsmeow e9a033b24933 (2026-07-22).

What I observed

In a group, a member's message arrived as a stanza carrying only a SenderKeyDistributionMessage (no user content), with both <enc> blocks tagged decrypt-fail="hide" and a <meta tag_reason="rereg_recovery_request"> (this happened shortly after I paired a fresh companion device, so I assume it's member re-registration recovery). Redacted:

<message addressing_mode="lid" from="<group>@g.us" id="<redacted>"
         participant="<redacted>@lid" participant_pn="<redacted>@s.whatsapp.net"
         type="text" t="...">
  <enc decrypt-fail="hide" type="pkmsg" v="2"><!-- 295 bytes --></enc>
  <meta appdata="member_tag" tag_reason="rereg_recovery_request"/>
  <enc decrypt-fail="hide" type="skmsg" v="2">...</enc>
</message>

This did not produce an events.UndecryptableMessage — it decrypted successfully and was dispatched as a normal events.Message whose RawMessage contains only SenderKeyDistributionMessage (handled internally by processProtocolParts, but still present on the dispatched event). So a downstream consumer that keys off message content sees an empty message and can't tell it apart from a genuinely lost/undecryptable one.

Questions

1. What does decrypt-fail="hide" mean on the receive path? From the token dictionary and message.go it's parsed into events.UndecryptableMessage.DecryptFailMode, but only on the decrypt-error branch. Is the intended semantic that a client should silently hide the message on failure (i.e. not surface any "waiting for this message" UI), the way the official clients apparently do?

2. Is emitting an events.Message for a content-less SenderKeyDistributionMessage (session-key redistribution, e.g. from rereg_recovery_request) the expected behavior? Or is there a recommended way to recognize/ignore these on the events.Message path so they aren't mistaken for real content?

3. Is DecryptFailMode (or the rereg_recovery_request / member_tag recovery context) ever exposed on the successfully-decrypted events.Message, or only on events.UndecryptableMessage?

Context: I bridge messages to another system, and these content-less recovery re-sends were being surfaced as "message couldn't be read" placeholders. I've worked around it by dropping events.Messages whose only field is SenderKeyDistributionMessage, but I'd like to confirm that's the right heuristic and understand the decrypt-fail="hide" contract. Thanks!