PDO placeholder-resend request for own outgoing media never answered when sent via iOS Share Extension
Description
When sending a media message (image) to a contact via the iOS WhatsApp Share Extension (i.e. sharing a photo from the Photos app or another app directly to a WhatsApp chat, without opening the main WhatsApp app), the own-device echo of that outgoing message consistently fails to decrypt on a linked device. The library correctly detects this and sends a PDO placeholder-resend request to the primary phone (BuildUnavailableMessageRequest / PDO / PLACEHOLDER_MESSAGE_RESEND), but the phone never answers it, and the message stays permanently undecryptable — no resolved events.Message is ever emitted for it, even minutes later.
The recipient receives the image normally through WhatsApp directly (delivery/read receipts confirm this) — only the linked device's own copy is affected.
Reproduction
Set up a linked device with a whatsmeow-based client (mautrix-whatsapp in our case, but likely reproducible with any whatsmeow client that has AutomaticMessageRerequestFromPhone enabled). On the iOS primary device, share an image from Photos (or another app, e.g. Immich) directly to a WhatsApp chat using the system Share Sheet — do not open the WhatsApp app itself. On the linked device: an UndecryptableMessage event fires for the own outgoing message (IsFromMe: true, Type: media), the library requests a resend from the phone (Requested message ... from phone), but no resolving message ever arrives — confirmed by waiting several minutes with no result. Control test: sending the same image directly from within the WhatsApp app (app open, in foreground, no Share Extension) works correctly every time — the linked device receives and decrypts the echo without issue, no undecryptable event at all.
We reproduced this consistently across multiple separate test messages (different message IDs, same chat) on the same day, always via the Share Extension, always unresolved; the app-based control test resolved every time.
Expected behavior
Either:
The PDO resend request eventually succeeds even when initiated from a Share Extension context (e.g. via a longer timeout/retry, since the Share Extension itself is short-lived but WhatsApp's main app process may still be reachable via push/background wake), or If this is an inherent protocol/OS limitation (the Share Extension process is likely killed by iOS before it can service the incoming phone-to-linked-device PDO request), it would help to document this limitation and/or have the library give up more gracefully / mark it clearly as unresolved rather than leaving the UndecryptableMessage state open indefinitely with no further signal.
Logs
DBG component=whatsmeow sublogger=Recv WRN Unavailable message 4A0FCDD240B6734E2F24 from 210861520076879@lid in 144336821993485@lid (type: "") component=whatsmeow DBG Stored message secret key for outgoing message 3EB071B3C9EDC547D35ED1 component=whatsmeow DBG ... component=whatsmeow sublogger=Send DBG component=whatsmeow sublogger=Recv DBG Requested message 4A0FCDD240B6734E2F24 from phone component=whatsmeow DBG component=whatsmeow sublogger=Send DBG Received undecryptable WhatsApp message decrypt_fail= info={"IsFromMe":true,"Type":"media","Chat":"144336821993485@lid","Sender":"210861520076879@lid",...,"unavailable":true} component=whatsmeow
No further resolving event ever appears for this message ID (confirmed via full log grep over several hours). We ended up manually deleting the message from the phone, which correctly triggered a revoke/RemoteEventMessageRemove event that removed the placeholder from the bridged Matrix room — so the library does clean up correctly on deletion, it just never resolves the original undecryptable state on its own.
Environment
Bridge: mautrix-whatsapp v26.08+dev.24064808 (commit 240648081e1ac70b6d5a530f57a6d26f317c9480, built Thu 03 Sep 2026 11:53:52 UTC, go1.27.0) whatsmeow: bundled with above bridge build (approx. go.mau.fi/whatsmeow v0.0.0-20260123225751-89be06b020db per current go.mod on main; exact pinned version for this specific bridge commit not independently verified) Sending client: WhatsApp for iOS, via system Share Sheet / Share Extension Linked device runs on a fresh VPS after a full data migration (Postgres + media store + signing keys restored from a previous working install); connection is otherwise stable (successful message send/receive, calls, and text messages all work normally)
I am not an english native speaker and AI helped me to write quick an ease this request.
Source: tulir/whatsmeow