After establishing a websocket connection to wss://pubsub-edge.twitch.tv, I send the following data to the server:
{
"type": "LISTEN",
"nonce": "abc123",
"data": {
"topics": ["channel-bits-events-v1.28640725"]
}
}
But I get the following response:
{"type":"RESPONSE","error":"Server Error","nonce":"abc123"}
I’ve tried this via both a Go websocket client and a JavaScript websocket in Chrome. The docs read:
OAuth token required to listen on some topics
but if it were required in this case, I would expect ERR_BADAUTH, rather than “Server Error”.
Code for reference:
const req = {
type: "LISTEN",
nonce: "abc123",
data: {
topics: ["channel-bits-events-v1.23161357"]
}
}
const ws = new WebSocket("wss://pubsub-edge.twitch.tv")
ws.addEventListener("open", (event) => {
const data = JSON.stringify(req)
console.log("send: " + data)
ws.send(data)
})
ws.addEventListener("message", (event) => {
console.log("recv: " + event.data)
})
Output:
send: {"type":"LISTEN","nonce":"abc123","data":{"topics":["channel-bits-events-v1.23161357"]}}
recv: {"type":"RESPONSE","error":"Server Error","nonce":"abc123"}
Is the problem still persisting?
Server errors are usually temporary so full restart your service and see if it’s good now
My connection overnight has been stable. But I’ve not issued a restart because I’m still ping ponging fine
Just restarted my service and the issue persists.
I tried including my own auth_token in the request, and I instead receive an ERR_BADAUTH response (expected behavior). Upon changing the auth_token to one linked to the owner of the channel, there are no errors.
It seems like the Server Error response only happens when the auth_token field is omitted from the request. I don’t know about you, but I feel like this is a bit misleading, and the error message should be changed to ERR_BADAUTH (or possibly ERR_BADMESSAGE) on Twitch’s end.
So you were getting server error when you passed no oauth at all?
The documentation https://dev.twitch.tv/docs/v5/guides/PubSub/ specifies only topics that require an oauth.
Yes I agree the error message is wrong, but there are no “unauthenticated” end points anyway.
@DallasNChains suggestion to add a better error message when no oauth provided in a LISTEN
I’m also experiencing this even with an auth_token.
Its just that the channel I’m listening to for bits actually does not have a bit cheers capability.
Does this error also pertain to that?
– Now everything is fine and working as expected…