search

errbotio / errbot

Errbot is a chatbot, a daemon that connects to your favorite chat service and bring your tools and some fun into the conversation.
http://errbot.io
GNU General Public License v3.0
3.09k stars 608 forks source link

XMPP backend delays sending replies until it receives some other communication #1598

Open nessuscity opened 1 year ago

nessuscity commented 1 year ago

Describe the bug When plugins reply to a message, the message is sent to the backend immediately. Other backends seem to process the messages correctly and the response is received quickly by the user. With the XMPP backend, messages are sent to the backend from plugins immediately, but the backend holds off transmitting the replies until it receives some other interaction, which can be any XMPP stanza.

To Reproduce

  1. Set up a minimal bot example using the minimal config for text mode
  2. Set up a new JID on an XMPP server so that it will not be receiving any incidental presence or iq stanzas that will hide the bug
  3. Change the backend to XMPP and add the only the required BOT_IDENTITY information
  4. Send !echo hello to the bot from an XMPP client that is configured NOT to send read state, chat markers, or anything else. The bot should not be receiving any stanzas except messages.
  5. Receive no reply (unless the XMPP keepalive or other stanza is received at just the right time to force the reply to be transmitted, thus hiding the bug)
  6. Send !echo world
  7. Receive "hello" and "world" messages from the bot simultaneously.

The buffered reply is also sent automatically if the bot receives any message or other stanza from another user or the server. In the absence of any such stanzas, the bot will hold onto the reply indefinitely.

Expected behavior The bot replies immediately with "hello"

Screenshots Attempts from main JID to use !echo command: image

Notice that when I sent a message from a separate JID to the bot, it replied on my main JID. The second time it responded on its own was due to the XMPP keepalive triggering. image

Environment (please complete the following information):

Additional context I've tested this on multiple machines with errbot from pip and from github. I believe the fact that any stanza received hides the bug is what allowed it to get thru testing. I have witnessed this behavior on another known XMPP errbot in the wild.

Logs also show that the XMPP backend's send_message method is being called at the correct time, but the actual response stanza is not sent until another one is received.

nessuscity commented 1 year ago

Setting BOT_ASYNC=False seems to fix the issue. I don't know enough about asyncio or threading to know if it's a bug that you can't use BOT_ASYNC=True with the slixmpp backend

Netzvamp commented 1 year ago

BOT_ASYNC=False doesn't fix messages to MUCs :(