[XMPP · Offline Delivery] Messages rejected with resource-constraint are later received and read #30
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
[XMPP · Offline Delivery] Messages rejected with resource-constraint are later received and read
Status: Investigation required. The contradiction between the reported rejection and subsequent delivery is confirmed by client logs, but the affected component and root cause are unknown.
Related confirmed UI issue: BUG_96_failed_status_persists_after_read_receipt.zip
Summary
Two messages sent to a suspended recipient received:
server_status=failed
fail_reason=resource-constraint
"Your contact offline message queue is full. The message has been discarded."
However, after the recipient reconnected, both messages were present in the chat, and the sender later received remote_status=read for the same message IDs.
Offline queue overflow itself is not reported as a bug here. The issue is the inconsistency between the reported rejection and the later confirmed delivery.
Environment
Sender: testman421@another.im, iPhone 13 Pro Max, iOS 26.7.1
Recipient: testman435@another.im, iPhone 17 Pro Max, iOS 27.2
App: v1.1.0 build 96 (feat/ui-redesign@e945d7cc)
libtacky: v1.2.0-rc4
1:1 OMEMO chat
Observed sequence
Recipient B was suspended and the device was locked.
Sender A sent two messages.
At 15:49:25 UTC, A received resource-constraint failures for both messages.
B reconnected at 15:51:29 UTC.
Both messages appeared on B after reconnect.
At 15:55:06 UTC, A received remote_status=read for both original message IDs.
A control message sent later was also delivered and read without a failure during the observed interval.
Message Sent (UTC) Failure (UTC) Read (UTC)
QA96_PUSH_LOCKED_02 15:44:25.264 15:49:25.488 15:55:06.044
QA96_PUSH_LOCKED_03 15:46:20.423 15:49:25.505 15:55:06.047
QA96_PUSH_ROUTE_04 (control) 15:53:02.088 — 15:55:06.049
For one of the affected messages, B's local record contains the same origin_id as the original send on A.
Investigation requested
Please correlate the message/stanza and origin IDs with server logs for 15:43–15:56 UTC on November 6, 2026, and determine:
the actual cause and scope of the resource-constraint errors;
the offline queue state and enqueue/dequeue activity at the time of the failures;
whether the messages were archived and how B later received them;
whether multiple copies or repeated processing were involved;
which delivery stage and stanza the error refers to;
how the backend should resolve the combination of server_status=failed and remote_status=read.
Limitations
Server logs and offline queue state were not available during testing. Queue limits were not changed or cleared.
The client evidence confirms the rejection events, subsequent presence of the messages on B, and read receipts for the same IDs. It does not establish whether the later delivery came through the offline queue, MAM, or another mechanism.
Completion criterion: establish the cause of the rejection and the path of subsequent delivery for the same message IDs, then determine whether a server or backend defect exists and define a separate reproducible scenario if necessary.
Moved to another-im/anotherim-server#3 with the analysis of the cause and a proposed fix: it is the server's to change. Closing here.