Twitch.listen doesn't trigger


#1

Hi, I looked into the forums and found a similar issue:

I am using the Twitch Developer Rig in osx, I am running this simple code:

const logToRig = (topic, loggable = '') => twitch.rig.log(topic, loggable);
const subscribeToTopic = () => {
    twitch.listen(
        'broadcast',
        (target, contentType, message) => {
            console.log(target, contentType, message);
        }
    );
    logToRig('listening...');
};

twitch.onAuthorized(function (auth) {
  logToRig('onAuthorized', auth);
    subscribeToTopic();
});

Logging show the auth is called, and that it reached the Listening line without errors.
From the backend I broadcast a message without any errors, tried both all and the actual channel id, but nothing seems to be received by the frontend.

Looking into the Chrome tools, I can see that all the WS connection are stuck at 101 Switching Protocols. These are the socket connection I can see:

wss://pubsub-edge.twitch.tv/v1
Initiated by: twitch-ext.min.js:22
// ---
wss://pubsub-edge.twitch.tv/v1
Initiated by coordinator.js:1

What am I doing wrong?

Thanks


#2

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?


#3

Thanks Barry for being so useful, what you wrote makes total sense, I assumed you needed auth to listen to broadcast, now I realise it didn’t make too much sense :smiley:

I am still experiencing the issue, backend works flawlessly with a 204 respone, the dev rig on the other hand doesn’t seem to care about my brodcasted messages.

Opening the console and refreshing the view I get this error:

twitch-ext.min.js:22 Uncaught (in promise) ERR_BADAUTH
value	@	twitch-ext.min.js:22
value	@	twitch-ext.min.js:1
value	@	twitch-ext.min.js:22

I still get those hanged connections, I tried with firefox and safari, and tried it with a vpn just in case my provider does something dodgy, no change at all, they still stay on 101. I even looked at http://websocketstest.com/ and it seems to work fine, what could be the issue here?
Thanks for your patience and understanding :pray:

This is my full js code:

const twitch = window.Twitch.ext;
let isAuthed = false;

const logToRig = (topic, loggable = '') => twitch.rig.log(topic, loggable);

twitch.onContext(context => logToRig('onContext', context));
twitch.onError(context => logToRig('onError', context));

twitch.onAuthorized(function (auth) {
    logToRig('onAuthorized', auth);
    logToRig('token', auth.token);
    isAuthed = true;
});

twitch.listen(
    'broadcast',
    (target, contentType, message) => {
        if (isAuthed) {
            logToRig('Broadcast', { target, contentType, message });
        } else {
            console.log('Ignored');
        }
    }
);

#4

Yeah you don’t as logged out users, and extension unlinked users in an extension can receive extension pubsub.

Yeah don’t refresh the view do the whole page.

101 is correct

You should get a frames tab if you want to look at the messages (chrome inspector)

It’s worth noting onAuthorised doesn’t mean “they have linked” it means “got a JWT that I can do stuff with” you’d need to test it, or use the helper JS functions to determine if they are linked or not, and if you want to process the message. (I realize I may have confused as I contracted my first reply, in the use of isAuthed as a var name, but it’s good to wait for onauth before processing, but usually onauth will happen without issue))

I don’t see anything wrong with the code. It is similar to my code.

So, are your PubSub-ing to the right channel? From your usage of “logToRig” I’m guessing this is in the extensions rig

Check which user you set the rig to, and you need to PubSub to that user