Right – the responses returned by the API are specifically for WebSockets, because this is what our web-client consumes. The IRC options are separate, but are also completely supported.
Edit: For AWS channels you’ll actually see both options in the response:
I have noticed my bot joined the wrong server for the chat of keizaron. I found out today that his chat was moved to the AWS servers. He isn’t partner or have subscriber buttons.
Just bringing this up as this might have happened to other chats too.
Silly question, as a developer of a bot (I won’t shamelessly promote the name here), is it possible to have a channel of a non-partner on our development team be placed into an AWS cluster for testing purposes? I understand that it should just be a quick flip and all goes well, but it would be great to be able to perform some unit testing ahead of time if possible.
Even when a channel is on the AWS cluster there still seem to be :tmi.twitch.tv SERVERCHANGE #channelname messages coming through: http://prntscr.com/adth4t
They seem to appear in batches of 3 for some reason. Is this normal behaviour and am I simply supposed to hide the message from the user or will the bot still have to disconnect & reconnect to the same AWS cluster every time it gets it even when it’s on the AWS cluster?
The AWS server behaves no different to regular server, only thing that is different is that the TMI endpoint returns only one Chat Server IP to connect to (per type), instead of a bucket load.
My understanding (which may be incorrect) of SERVERCHANGE is that any time you join an incorrect cluster, it sends the alert to change servers. This means (If the previous statement is correct) that if you join AWS and get a SERVERCHANGE message, your channel got moved back to main.
In my case the bot I created was never meant to connect to multiple servers, so this slow change just breaks everything for me.
I don’t really get why changing everyone to the new servers at once would be more problematic than slowly moving them.
In the first case there are 2 servers to connect to and we have to look up which one for which channel, in the other there’s just one line to change: the DNS.
Because when you’re managing 20+ servers that are split into clusters (IE: Main, event, aws, group, whisper, etc) things have way different performance at small scale than large scale. It could be rock solid and stable at say 10k channels, but at 15k you could exceed the computers cpu processing limit, and it basically falls off a cliff and dumps all or most people connected. The scale up ensures that you minimize the risk of cliffs and random server outages.
Your ‘2 servers’ is actually a cluster of servers on twitches end that you access through two endpoints that get translated to a specific server.
I’m running two instances of the bot in my case, as its poorly programmed, and haven’t gotten to changing it yet. Connect to the old chat cluster, and one on the new aws cluster.
Running a second instance on the other chat cluster will be the best option for most people as the situation is temporary and, if all goes well, event chat will go away with this too.