Messages sent with prekey (pkmsg) on every send — sessions not reused

[ricott1]

Summary

Messages sent via client.send_message() always use enc type="pkmsg" (prekey messages) instead of reusing established Signal protocol sessions (enc type="msg"). The WhatsApp server ACKs the messages, but recipients never receive them — likely because the prekey bundles are exhausted or the sessions established during encryption aren't persisted between sends.

Reproduction

1. Authenticate a new session (QR code pairing)
2. Send a message to a contact — works initially
3. Send another message to the same contact — still uses pkmsg
4. Recipient never sees the messages (server ACKs but delivery fails silently)

Log Evidence

Every outgoing message uses pkmsg for the recipient, even after multiple sends to the same contact:

<!-- First send -->
<message id="3EB041..." to="49157...@s.whatsapp.net" type="text">
  <participants>
    <to jid="49157...@s.whatsapp.net"><enc type="pkmsg" v="2"/></to>
    <to jid="39366...@s.whatsapp.net"><enc type="msg" v="2"/></to>  <!-- own device: reused -->
  </participants>
</message>

<!-- Second send to same contact — still pkmsg, should be msg -->
<message id="3EB0F1..." to="49157...@s.whatsapp.net" type="text">
  <participants>
    <to jid="49157...@s.whatsapp.net"><enc type="pkmsg" v="2"/></to>
    <to jid="39366...@s.whatsapp.net"><enc type="msg" v="2"/></to>
  </participants>
</message>

Note: the sender's own devices correctly use enc type="msg" (established session), so session persistence works for self-devices but not for remote contacts.

Expected Behavior

After the first pkmsg to a contact, subsequent sends should use enc type="msg" (the Signal session established during the first send should be persisted and reused).

Environment

• whatsapp-rust v0.4.1
• Custom ProtocolStore implementation backed by SQLite (put_session/get_session using INSERT OR REPLACE)
• macOS, Rust nightly

Workaround

Deleting the database and re-pairing temporarily fixes it, but the issue recurs after some time.

Possible Cause

The session established during send_message_impl() may not be getting committed to the store, or the session lookup is using a different address format than what was stored. The fact that self-device sessions work correctly suggests the issue is specific to how remote contact sessions are keyed/stored.

[jlucaso1]

Hmmm nice catch, I'll take a look

[ricott1]

I think the fix is quite simple actually, u need to clear the unacknowledged prekey items from the state when u send. I fixed in my fork and it seems to work

[ricott1]

I opened this issue because messages sent where not arriving to the recipient and I pointed it down to the fact that messages wrapped as pkmsg don't arrive. If I understand correctly, pkmsg wrapping shouldn't prevent delivery, it's just extra metadata. I will investigate more tmrw :)

[ricott1]

Hello hello, good sunday!

Update: I did more investigation on this and maybe I've found the root causes. The AdvSignedDeviceIdentity is lost on restart because Device.account is marked #[serde(skip, default)], so it's never persisted when the DeviceStore serializes the device.

Without account, the element is missing from outgoing message stanzas and recipients silently drop pkmsg from companion devices they can't verify. That's why messages appeared to send (server ACKs them) but never arrived.

Note: in v0.3.0, account had no serde(skip), so it was serialized and persisted normally. The #[serde(skip, default)] was added in 4a1d2ec (PR #393), which landed between v0.3.0 and v0.4.0. I think that's when it broke.

4a1d2ec#diff-42378bea8aa06499bf4395703987b4fb5887ac1eb5d23725092fed3a1443899fR105

[jlucaso1]

Hello, good sunday! I'll take a look, thank you for the investigation

[jlucaso1]

I'll implement a custom serializer/deserializer for this field (like the one in SQLite storage, which is why I didn't have the problem the first time). Good catch.