Tickets :: [#264] MUC MAM custom IQ request responses are dropped

5.2.23

10/04/2023

Summary	MUC MAM custom IQ request responses are dropped
Queue	gloox
Queue Version	1.0.16
Type	Bug
State	Resolved
Priority	3. High
Owners	js (at) camaya (dot) net
Requester	tom (at) madglory (dot) com
Created	09/12/2016 (2578 days ago)
Due
Updated	11/10/2016 (2519 days ago)
Assigned
Resolved	11/10/2016 (2519 days ago)

11/10/2016 01:52:54 PM	Jakob Schröter	Comment #4 Assigned to Jakob Schröter State ⇒ Resolved	Reply to this comment
Hi, sorry for the delay in fixing this. Your patch looks good and I have now fixed this in SVN as well. Will be in 1.0.18.

10/04/2016 02:32:03 PM	tom (at) madglory (dot) com	Comment #3 New Attachment: gloox-1.0.16-MUCRoom_handle_msg_extension_20161004.patch	Reply to this comment
Hello, We made a patch for gloox-1.0.16 to allow MUC messages with an empty body if they have any extensions to allow MUC MAM responses though the normal flow and trigger the handleMUCMessage callback. Does this patch look sane? Does it have any obvious unintended side-effects?

09/23/2016 03:07:01 PM	brian (at) madglory (dot) com	Comment #2	Reply to this comment
Hi Jakob - Would it be possible to get some direction on this? The "fix" is clear, we should allow messages through that don't have a body. However, we're unclear if that's something that would break other use cases for the library. Also, rather than maintain a fork, we'd like to see this in core. Thanks, Brian [Show Quoted Text - 30 lines][Hide Quoted Text] Hello, We are trying to write a custom StanzaExtension to request/receive MAM history for a MUC. We are able to form the IQ stanza to request history from the room, and we see Message stanzas returned and are able to parse the enclosed historic Message in newInstance(tag), but the Message does not seem to be firing handleMUCMessage of the parent ClientBase. Our code gets to line 1083 in mucroom.ccp (gloox 1.0.16) where it’s checking "else if( !msg.body().empty() )”. The response outer message does not have a body itself, just an embedded stanza that has the archived body. I think it’s dropping the message here. Similar code is working to request 1to1 MAM history between two users, and fires handleMessage of the parent ClientBase correctly. Here is an an example MUC MAM request: https://gist.github.com/tquackenbush/2ab7054c436de7605acef99cd1d13d8c MUC MAM response Message stanza https://gist.github.com/tquackenbush/ac8c0a2787575acc63156fa2a4b301dc This is related to ticket [#145] Support for Message Archiving (XEP-0136) (https://bugs.camaya.net/ticket/?id=145)

09/12/2016 06:37:58 PM	tom (at) madglory (dot) com	Comment #1 Summary ⇒ MUC MAM custom IQ request responses are dropped Type ⇒ Bug Priority ⇒ 3. High State ⇒ Unconfirmed Queue ⇒ gloox	Reply to this comment
Hello, We are trying to write a custom StanzaExtension to request/receive MAM history for a MUC. We are able to form the IQ stanza to request history from the room, and we see Message stanzas returned and are able to parse the enclosed historic Message in newInstance(tag), but the Message does not seem to be firing handleMUCMessage of the parent ClientBase. Our code gets to line 1083 in mucroom.ccp (gloox 1.0.16) where it’s checking "else if( !msg.body().empty() )”. The response outer message does not have a body itself, just an embedded stanza that has the archived body. I think it’s dropping the message here. Similar code is working to request 1to1 MAM history between two users, and fires handleMessage of the parent ClientBase correctly. Here is an an example MUC MAM request: https://gist.github.com/tquackenbush/2ab7054c436de7605acef99cd1d13d8c MUC MAM response Message stanza https://gist.github.com/tquackenbush/ac8c0a2787575acc63156fa2a4b301dc This is related to ticket [#145] Support for Message Archiving (XEP-0136) (https://bugs.camaya.net/ticket/?id=145)