Description
There is an intermittent issue during message decryption where Baileys throws:

No session found to decrypt message

This happens when the SenderKeyRecord has no states:

{
  senderKeyMessageBytes: <Buffer ...>,
  record: SenderKeyRecord { MAX_STATES: 5, senderKeyStates: [] },
  keyId: 1448433113
}

The failure is sporadic and has been occurring for some time (not related to recent merges). It appears more frequently in Baileys ↔ Baileys communication.

Observed behavior

• Decryption fails due to missing session/state.

• Retry mechanism is triggered but:

  • Retry messages are not always properly handled.
  • Even when retry is received, the error persists.

• SenderKeyRecord.senderKeyStates is empty when attempting decrypt.

Investigation notes

• Baileys does not seem to process keys sent in retry receipts.

• Comparing with whatsmeow:

  _, hasKeys := node.GetOptionalChildByTag("keys")
  var bundle prekey.Bundle
  if hasKeys {
      bundle, err = nodeToPreKeyBundle(uint32(receipt.Sender.Device), node)
      if err != nil {
          return fmt.Errorf("failed to read prekey bundle in retry receipt: %w", err)
      }
  }

  → whatsmeow parses and applies prekey bundles from retry.

• Baileys also does not send SKDM (Sender Key Distribution Message) on retry resend.

• Comparing with other implementations (whatsmeow / wpp-rust), there are missing steps around SKDM handling.

Hypothesis

• Missing handling of keys in retry receipts prevents proper session reconstruction.
• Absence of SKDM on retry resend may leave the receiver without required sender key state.

Steps to reproduce
Not deterministic. Occurs sporadically, more commonly in Baileys-to-Baileys messaging under retry conditions.

Environment

• Baileys: master branch
• Issue present for a while (not introduced recently)

Additional context
Still investigating SKDM and retry flow to confirm root cause. Initial analysis suggests gaps in retry key handling compared to other implementations.