Hubot connects (and joins rooms) but acts deaf

[javmorin]

I tried setting up Hubot this evening against my companies ejabberd xmpp system. Hubot seems to connect and joins the prescribed MUC , however it does not list as being online/available, nor does it respond to any commands via the group chat or when prompted directly. I am able to run with the shell adapter and get expected responses, so the issue appears isolated to the xmpp adapter.

Would be happy to help debug the problem, but I am a nodejs newbie, so I am not sure of even where to start.

[markstory]

Interesting, I've not hit that issue on my jabber network. As for a place to start debugging, the adapter's run() method binds to the message events. It might be worthwhile sprinkling in some console.log to see what message stanza's are coming in

[jamiereid]

I'm having the same/similar trouble on my Openfire server. Hubot connects, joins the room, but doesn't respond to messages (even directly) (Shell works fine). Happy to help debug, but like caos, I too am a newbie.

[jamiereid]

If I understand correctly, putting "console.log(message)" after "message = body.getText()" in the "readMessage: (stanza) =>" function shows that hubot is listening to the chat (it prints out all messages sent to chat).

[markstory]

Yeah, you'd want to see why the bot isn't replying. There are a number of checks that reject messages, one of those must be catching the commands. Knowing what the incoming stanzas, and the config looks like might help.

[jamiereid]

The stanza looks like (minus the opening and closing quotes):

"
{ name: 'message',
parent: null,
attrs:
{ type: 'groupchat',
id: 'purple249d964b',
to: 'hubot@host.fq.dn/7cb5c38e',
from: 'ncs@conference.host.fq.dn/user',
'xmlns:stream': 'http://etherx.jabber.org/streams',
xmlns: 'jabber:client' },
children:
[ { name: 'body',
parent: [Circular],
attrs: {},
children: [Object] } ] }
"

body contains:

"hubot image me firefly"

not sure what config you wanted?

"
Mon, 05 Dec 2011 03:51:50 GMT] INFO { username: 'hubot@host.fq.dn',
password: 'hubotpassword',
host: undefined,
port: undefined,
rooms: [ { jid: 'ncs@conference.host.fq.dn', password: false } ],
keepaliveInterval: 30000 }
"

[jamiereid]

direct IM stanza looks like:

"
{ name: 'message',
parent: null,
attrs:
{ type: 'chat',
id: 'purple249d9658',
to: 'hubot@elvis.mgmt.educ/665deebd',
from: 'ncs@conference.elvis.mgmt.educ/jreid',
'xmlns:stream': 'http://etherx.jabber.org/streams',
xmlns: 'jabber:client' },
children:
[ { name: 'active',
parent: [Circular],
attrs: [Object],
children: [] },
{ name: 'body',
parent: [Circular],
attrs: {},
children: [Object] } ] }
"

and the body is "hubot image me bender"

[incanus]

I'm seeing this too against ejabberd. Unlike Shell or IRC, which I've tested with the same configuration, chat room messages aren't being logged to the console as they come in (i.e., Hubot overhearing/parsing every line) with the XMPP adapter.

[incanus]

Did a bit of debugging (somewhat newbie territory here as well) and determined that readMessage: seems to be running through properly, passing proper arguments to @receive new Robot.TextMessage user, message. Just never hear back from it.

For example, I can confirm that every message in the room is seen, and is debug-outputted from message. I can also determine a user is being created and, if necessary, persisted to Redis.

The user.name, user.room, and user.type all look correct (though user.type is stuff like groupchat, which seems weird to me, but that's what it says to do.

Nothing is attempted to be sent, as a console.log at the top of send: never gets called.

So unless the XMPP adapter isn't fulfilling its API contract with something up the chain, I'm not sure what's going on here?

[jamiereid]

Agreed; I came to the same conclusions this morning when I did some testing.

[incanus]

Also FWIW, Redis reports a user entry consisting of id, name, and jid for Hubot, but for my user, id, name, room, and type (i.e. groupchat).

[andyfowler]

Oh, just noticed that an issue was open. See my pull request. It fixes this. The problem is this module's dependency on hubot. rm -rf node_modules/hobot inside the adapter as a hack for now

[markstory]

I took a look at the stanza's my jabber server sends, and they are surprisingly similar. You should see messages at least get as far as https://github.com/markstory/hubot-xmpp/blob/master/src/xmpp.coffee#L92, That's the final check to reject a message. I don't think any of the other cases should apply based on the stanza's you pasted earlier.

[jamiereid]

Tested. The pull from @andyfowler worked :)

[incanus]

Ok, so @andyfowler's patch & hubot-xmpp 0.0.4 solve the problem, but now we're back with this from the Hubot v1 days: hubotio/hubot#186

[jamiereid]

@incanus I'm not having that problem..
[15:47] jreid: hubot throw a coin
[15:47] hubot: jreid: heads

hubot 2.0.5
hubot-xmpp 0.0.4

[incanus]

I was able to fix the undefined user issue by clearing my users variable in Redis. I'm all resolved here!

[javmorin]

Wow.. that was quick. I step away for a day, and when I get back the problem is fixed. Thanks @andyfowler!

I can confirm that the xmpp adapter now works on my ejabberd instance via group chat. There appears to be a parsing error for direct chat, but I will try and dig into that and file an issue/pull request as appropriate.