Maybe Gabble should retry sending the stanza if it gets a 'wait' error?

I can confirm this bug.

$ rpm -qa | grep -E "telep|empat"
telepathy-gabble-0.12.7-1.fc16.x86_64
python-telepathy-0.15.19-3.fc16.noarch
telepathy-haze-0.5.0-1.fc16.x86_64
telepathy-filesystem-0.0.2-2.fc15.noarch
telepathy-mission-control-5.10.1-1.fc16.x86_64
telepathy-butterfly-0.5.15-3.fc16.noarch
telepathy-farsight-0.0.19-1.fc16.x86_64
telepathy-glib-0.16.0-1.fc16.x86_64
empathy-3.2.1.2-1.fc16.x86_64
telepathy-idle-0.1.10-1.fc16.x86_64
telepathy-salut-0.6.0-1.fc16.x86_64
telepathy-logger-0.2.10-2.fc16.x86_64

Also this bug can be reproduced in MUC by sending messages as "nick: some-url". If URL has been pasted (by Ctrl+V, as exmaple).

Yeah, just want to confirm. It seems I have the same issue with some XMPP-servers: https://bugzilla.gnome.org/show_bug.cgi?id=663001

For user no russian language use: http://translate.google.com/
---

Я подтверждаю такой баг.
Fedora 16 ( 3.1.1-2.fc16.x86_64 )
empathy-3.2.1.2-1.fc16.x86_64

confirm

$ rpm -qa | grep -E "telep|empat"
telepathy-butterfly-0.5.15-3.fc16.noarch
telepathy-farsight-0.0.19-1.fc16.i686
telepathy-glib-0.16.0-1.fc16.i686
telepathy-filesystem-0.0.2-2.fc15.noarch
python-telepathy-0.15.19-3.fc16.noarch
telepathy-haze-0.5.0-1.fc16.i686
telepathy-salut-0.6.0-1.fc16.i686
telepathy-gabble-0.12.7-1.fc16.i686
empathy-3.2.1.2-1.fc16.i686
telepathy-idle-0.1.10-1.fc16.i686
telepathy-mission-control-5.10.1-1.fc16.i686
telepathy-logger-0.2.10-2.fc16.i686

In the more new version of Empathy/Telepathy the bug still exists:

$ pacman -Q |  grep -E "telep|empat"
empathy 3.2.2-1
python-telepathy 0.15.19-1
telepathy-butterfly 0.5.15-1
telepathy-farsight 0.0.19-1
telepathy-farstream 0.1.2-1
telepathy-gabble 0.14.0-1
telepathy-glib 0.16.2-1
telepathy-haze 0.5.0-1
telepathy-idle 0.1.11-1
telepathy-logger 0.2.12-1
telepathy-mission-control 5.10.1-1
telepathy-salut 0.6.0-1
telepathy-sofiasip 0.7.1-1

There is no need to add “me too” comments: we are aware that the issue exists, and since this bug is not marked FIXED, newer versions should not be expected to fix it.

I wrote a quick test. http://cgit.collabora.com/git/user/wjt/telepathy-gabble-wjt.git/commit/?h=43166-muc-rate-limit

At present, the error is exposed as Too_Long <http://telepathy.freedesktop.org/spec/Channel_Type_Text.html#Enum:Channel_Text_Send_Error>. Which is not necessarily right. We do correctly use Temporarily_Failed, though. I guess Empathy could use that to distinguish between “too long” and “slow down”.

The spec does say that Empathy “SHOULD notify the user, but MAY automatically try sending another copy of the message” in response to Temporarily_Failed. <http://telepathy.freedesktop.org/spec/Channel_Interface_Messages.html#Enum:Delivery_Status>

If you are unable to properly handle a warning from the server in the chat,
what can be done now, just disable this?
(As in pidgin, tracking is only in conversations in a chat no)
Since the current position to use empathy to chat CAN NOT!

Just now I got this in a MUC in reply to a legitimate message I sent:

* message xmlns='jabber:client' id='54daefbe-5163-4bce-987b-3303959d6d0e' type='error' to='will.thompson@collabora.co.uk/Queeg' from='prosody@conference.prosody.im'
    * error type='wait'
        * policy-violation xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'
        * text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'
            "The room is currently overactive, please try again later"
    * body
        "fair enough"

Empathy told me: “Error sending message 'fair enough': unknown”.

This is a slightly different case though: I just would like Empathy to show the text the server sent me (and make sure Gabble exposes it).

http://cgit.collabora.com/git/user/wjt/wocky/log/?h=muc-fixes adds policy-violation to the set of XMPP errors recognised by Wocky, fixes a bug which clobbered the type='' attribute, and passes more details of the error (including its message) to the WockyMuc API user.

http://cgit.collabora.com/git/user/wjt/telepathy-gabble/log/?h=43166-muc-rate-limit makes Gabble map policy-violation to Permission_Denied and include the error text in the delivery report. Unfortunately it exposes a tp-glib bug/issue: the legacy Received signal gets the text of the error from the server (which seems fine) but loses the Non_Text_Content flag (because there is text content). I can't really be bothered to fix it though.

I want to also make GabbleMucChannel turn off sending delivery reports if it ever gets an <error type='wait'> for a <message> it sends, to improve the failure case originally reported in this bug, but haven't done that yet.

(In reply to comment #10)
> http://cgit.collabora.com/git/user/wjt/wocky/log/?h=muc-fixes adds
> policy-violation to the set of XMPP errors recognised by Wocky, fixes a bug
> which clobbered the type='' attribute, and passes more details of the error
> (including its message) to the WockyMuc API user.

Looks good.

> http://cgit.collabora.com/git/user/wjt/telepathy-gabble/log/?h=43166-muc-
> rate-limit makes Gabble map policy-violation to Permission_Denied and
> include the error text in the delivery report.

Also looks good, apart from a 'print parts' that crept into the last commit.

> Unfortunately it exposes a
> tp-glib bug/issue: the legacy Received signal gets the text of the error
> from the server (which seems fine) but loses the Non_Text_Content flag
> (because there is text content).

Hmm. I think the solution to this is probably that Message_Type_Delivery_Report should trigger Non_Text_Content? In my original draft of DeliveryReports, they would have had { 'interface': '...DeliveryReports' } in the header, which I think does trigger Non_Text_Content, but that was lost when delivery reports became a core part of Messages in a later draft.

This might be a bit more significant than it looks, because on the client side, telepathy-glib Messages clients use the same code to make tp_message_to_text() output Non_Text_Content if necessary.

If you don't want to fix this right now, please open the bug.

(In reply to comment #11)
> > http://cgit.collabora.com/git/user/wjt/telepathy-gabble/log/?h=43166-muc-
> > rate-limit makes Gabble map policy-violation to Permission_Denied and
> > include the error text in the delivery report.
> 
> Also looks good, apart from a 'print parts' that crept into the last commit.

And apart from the commit whose name included "WIP", and that last commit being a test that didn't pass, both because of bug 61254 and it being incomplete. I've updated both now. :)

> If you don't want to fix this right now, please open the bug.

Fixed over on bug 61254.

No, original bug reporter, my branches here don't fix your case yet, but they are working towards it!

(In reply to comment #12)
> No, original bug reporter, my branches here don't fix your case yet, but
> they are working towards it!

And now, the top three patches of http://cgit.collabora.com/git/user/wjt/telepathy-gabble/log/?h=43166-muc-rate-limit do a little more clean-up and then fix the original bug as best we can: if we ever get a <message type='error'><error type='wait'> from a MUC, we disable sending typing notifications for that MUC. This still means that the first time you send a message very quickly, the message will be rejected and you'll have to re-send it, but it's at least recoverable.

https://bugzilla.gnome.org/show_bug.cgi?id=694251 is an untested Empathy branch which, together with this Gabble branch, should make the chat window show the error message from the server (in this case, "Traffic rate limit is exceeded") rather than a string corresponding to one of http://telepathy.freedesktop.org/spec/Channel_Type_Text.html#Enum:Channel_Text_Send_Error (in this case, Too_Long, because that's the best code we have for this situation, and the server genuinely rejecting the message because it's too long looks the same to us as the server rate-limiting some other way).

Merged to Gabble master for 0.17.3.