disconnected event not a catch-all

[samuri51]

i don't know if this is the right place to post this but i've been noticing over the last week or so that sometimes the bot will still be in the room but completely unresponsive. it has not actually crashed because when i purposely induced a web socket error by unplugging my internet cable, the "disconnected" event at that time did fire and the bot reconnected to the room and started functioning normally again. so i guess there's still some x-factor that if it happens the bot will not be connected but a web socket error has not occurred either? let me know if i should be asking this somewhere else...

[alaingilbert]

Thanks for letting us know ! This is the very right place for this kind of comment :)

Though, I really don't know what could cause this.

[gizmotronic]

Could you elaborate on what you mean by unresponsive? There's a funny situation that I see on the web client every once in a while, most recently a week or so ago, where you look like you're in the room on your end (can hear music, can see public chat, etc.) but you can't interact with the room at all. From the perspective of everyone else in the room you've left the room. Does it look something like that? Or, is it that you can see the bot still in the room, but it just doesn't respond?

The case where the server stops responding is something one of my earlier changes addresses. Every 10 seconds we send a presence update to the server and expect a response. If we send these for more than 2 minutes without a response you should see a disconnected event fired.

Is this something you can easily reproduce, or have seen regularly? It might be helpful to turn on debugging to see if you're getting responses from the server when your bot is in this state.

[edited to clarify that the first example is on the web client, not a bot]

[samuri51]

i know exactly what your talking about, but as far as unresponsive. i mean i can refresh the page and talk to other people in the room but when i pm the bot or send it commands it says its offline. yet it is still in the room. and yeah ill turn on debug for sure

[samuri51]

as far as reproduceable its happened to me several times. i don't know exactly what to do other than just wait. there's never any stack trace or anything

[samuri51]

alright after turning on bot.debug it appears i am getting this error:

events.js:71
        throw arguments[1]; // Unhandled 'error' event
                       ^
Error: write Unknown system errno 1450
    at errnoException (net.js:769:11)
    at Object.afterWrite (net.js:593:19)

any idea what this means? i'm assuming it has something to do with web sockets

[gizmotronic]

Without a full trace it's hard to say where that's coming from. You might find it helpful to add an error event handler, e.g.:

bot.on('error', function (e) {
  console.log(e.stack);
});

If the error is coming from Turntable-API you should be able to see what's going on.

[samuri51]

alright

[samuri51]

still havent gotten that error event, but one thing that did happen was that the bot sent "bot is not ready. can't send : 'presence.update'" for well over 10 minutes with no disconnected event being fired

and no it didn't work later on

[samuri51]

looks like its not working due to line 344 of the compiled bot.js file Bot.prototype._send function... its not ever allowing it to send a presence update or anything else so its not being tripped either because its literally not even letting that code execute. i guess that explains why my recovery code based on speaking isnt working either... says bot is not ready cant send bot.speak so of course theres no callback.success .... and no i don't have a fix for it

[samuri51]

in summery: presence updates aren't a legitimate way to check if your connected or not, because when your not connected you can't send presence updates.... (due to the fact that your not authenticated)

[gizmotronic]

The "bot is not ready" message comes from _send() if the internal _isAuthenticated flag evaluates to false and the request is not user.authenticate. The curious thing here is that once you've connected, there's only one place that the internal _isAuthenticated flag is set to false: in the disconnect() function. This happens to also be where we emit either a disconnected event (if there are listeners for it) or an error event (if not).

If it were me I'd be really tempted to hand-edit node_modules/ttapi/lib/bot.js and insert a console.error at the start of the disconnect function to see whether it ever gets there.

[gizmotronic]

Did you make any progress on figuring out what was going on here? I'll admit I'm pretty puzzled.

[samuri51]

nope, been running it continuously but haven't gotten that error yet. obviously tho if you get an error one time its possible to get it again, just a matter of time

[samuri51]

hm, some weird stuff happening... i saw today when my internet cut out it did actually fire a disconnected event and rejoined the room, but was stalled out and isAuthenticated was still false so it wasn't doing anything for about 5 minutes, then it fired another disconnected event and rejoined the room and now isAuthenticted was set to true so it was working normally again. idk probably some weird low level thing going on in my code, i am noticing i'm getting a lot of undefined values lately even though when i look a the code i don't see anything to suggest that i'm creating them.

edit: the undefined values are calls to data.name and data.userid mostly

[samuri51]

i'm gonna try and monitor it to see if those values are coming from the callback or if they're becoming undefined overtime