MUC groupchat message with subject and thread is mishandled

[singpolyma]

https://xmpp.org/extensions/xep-0045.html#subject-mod

The subject is changed by sending a message of type "groupchat" to the <room@service>,
where the <message/> MUST contain a <subject/> element that specifies the new subject
but MUST NOT contain a <body/> element (or a <thread/> element).
In accordance with the core definition of XMPP, other child elements are allowed
(although the entity that receives them might ignore them).

Note: A message with a <subject/> and a <body/> or a <subject/> and a <thread/>
is a legitimate message, but it SHALL NOT be interpreted as a subject change.

Sending a subject and a thread to an ejabberd MUC is interpreted as a subject change.

[badlop]

Sending a subject and a thread to an ejabberd MUC is interpreted as a subject change.

The room subject is changed only when the message stanza doesn't include body and no thread, as implemented in

https://github.com/processone/ejabberd/blob/6eff14a71d875b211e895d2e911de6813f227cc7/src/mod_muc_room.erl#L3037-L3039

You can verify that in the muc_room table. If using Mnesia, this can be seen in the ejabberd WebAdmin -> Nodes -> your node -> Database -> muc_room -> elements. There you can confirm that the room subject didn't change.

http://localhost:5280/admin/node/ejabberd@localhost/db/muc_room/1/

What you have noticed is that ejabberd sends that message stanza to the room occupants. If your client does not implement the verification mentioned in the XEP, then your client may display a subject change.

What did you expect the server to do? Block such a stanza? Remove the subject element? Remove the body/thread element? Nothing of that is mentioned in the XEP.

[singpolyma]

Apologies, it does seem like this was a bug in the clients I was testing and not a server bug.