Opened 5 years ago

Last modified 5 years ago

#15864 new defect

error stanzas not handled correctly (not shown to users)

Reported by: mhellwig Owned by: deryni
Milestone: Component: XMPP
Version: 2.10.7 Keywords:


I am using XEP-0198 with a prosody server and yaxim as client (yaxim in the nightly version that supports it) and pidgin as the second partner in the chat. For the case where the client (yaxim) loses connectivity and reconnects before the session timeout runs out, everything works great. For the case where the session timeout happens, there is the following problem.

According to XEP-0198, "A server SHOULD treat unacknowledged stanzas in the same way that it would treat a stanza sent to an unavailable resource, by either returning an error to the sender or committing the stanza to offline storage." I.e. it is legal for the server to return an error. The implementation of XEP-0198 for prosody does this as described here namely "If the client fails to reconnect before the timeout then it is marked offline as normal, and any stanzas in the queue are returned to the sender as a "recipient-unavailable" error."

From what I understand and have seen, this error is a stanza that has the same message ID as the original message it relates to, no content and is of 'type="error"'.

If pidgin as a sender receives such an error (because the intended recipient of the message lost network connectivity long enough to trigger the timeout on the server) it SHOULD (imo) inform the sending user of this error. It doesn't. IMO this is a bug.

It is clear from the server debug logs that the error stanza is received by pidgin, pidgin just doesn't show anything to the user.

Change History (3)

comment:1 Changed 5 years ago by deryni

pidgin does display error messages that contain contents. Try sending a message to a jid that doesn't exist. I'll grant that that display is not the greatest (and it should probably be moved into the conversation window) but if the error message has no content then pidgin doesn't (as far as I can recall offhand) have any way of connecting it back to the specific message that triggered it (it doesn't keep track of message id:s internally that way).

It should be possible to make this work but it will require some amount (I don't know exactly how much) of work to wire up the right pieces.

comment:2 Changed 5 years ago by elrond

Well, one could assign message-ids, that contain some unique conversation-id and a message-counter. That way the error could at least be shown in the correct window/tab? That way the user at least knows, that some (most likely the last) messages were lost.

comment:3 Changed 5 years ago by deryni

Even without that it should be possible to show a generic message in the conversation window. And while that is certainly more helpful than dropping the error I'm not certain how actively helpful that actually is.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!