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:
Initiated by: twitch-ext.min.js:22
Initiated by coordinator.js:1
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?
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
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
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