Modify

#1114 new defect

XMPP: bitlbee receives but does not display stanzas of type "error"

Reported by: mhellwig@… Owned by:
Priority: major Milestone:
Component: BitlBee Version: 3.2
Keywords: Cc:
IRC client+version: Client-independent Operating System: Linux
OS version/distro:

Description

I am using XEP-0198 with a prosody server and yaxim as client (yaxim in the nightly version that supports it) and bitlbee 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 http://code.google.com/p/prosody-modules/wiki/mod_smacks 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, 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 bitlbee 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 as well as the xmlconsole in bitlbee that the error stanza is received by bitlbee, bitlbee just doesn't show anything to the user.

In order to be able to show a meaningful error message to the user (as discussed a few days ago in the bitlbee IRC channel) it would probably be necessary for bitlbee to create and send message IDs (which it currently doesn't). If said message IDs were e.g. timestamps one could at least display a "warning, message from 'time' was not received by intended recipient". Without message IDs (which is currently the case), the only option is "warning, X number of messages could not be delivered".

Attachments (0)

Change History (1)

comment:1 Changed at 2014-02-11T13:31:25Z by dx

Priority: normalmajor

Modify Ticket

Action
as new The ticket will remain with no owner.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.