Don’t put it in the onAuthorzied call back
Do something like this for example. 99% of the time isAuthed is gonna be true since onAuthorised always fires. But you can test isLinked and other parts inside your listen processor
const logToRig = (topic, loggable = '') => twitch.rig.log(topic, loggable);
let isAuthed = false;
twitch.listen(
'broadcast',
(target, contentType, message) => {
if (isAuthed) {
console.log(target, contentType, message);
} else {
//ignore as not authed
}
}
);
twitch.onAuthorized(function (auth) {
logToRig('onAuthorized', auth);
isAuthed = true;
});
Consider this:
A user loads the page, they are not linked yet.
Under your code (if it worked) it would raise the listen as onAuthorised is fired (fires for all users in all states)
A user then links, onAuthorised is called again, and a second listen request is raised.
You are now listening twitch (as linking doesn’t cause a page reload/code restart).
Also there are a number of race conditions and weird hiccups from calling a listen instead a onAuthorised.
This was found and solved under
This sounds like a separate issue, as these connections are made whether you listen or not. The call to listen just adds a subscription topic. If it’s stuck on connecting could indicate a issue with your connectivity to Twitch, it’s also possible but unlikely a plugin installed to chrome could be interferring (but thats very unlikely)
I’m assuming you tested this both in the Rig, and under “View in Browser” from the Rig and got similar issues with the stalled connection?