When I subscribe to something, I would like to receive a first notification with the current status of the susbcription (stream changed hook).
Right now I receive an empty data notification.
All I do now is to subscribe and when subscription is done, then ask for the current stream. The problem is that I can reach a race condition where while I’m getting the stream status, I receive a hook notification where the stream has changed but I’m still receiving an old stream status. Or also that different cache endpoints are reached (sometimes when you ask for a stream status in a small period of time, you receive online/offline alternatively).
Also, this increases amount of requests, because for each subscription I have to do a “get stream for id” api call.
Err no, to clarify, you make a HTTP post, to which you get a HTTP 204 Created, no body.
Twitch then sends a GET challenge request to you callback and then you reply to that callback with the challenge.
Then you will get body content posted to you when the state of the stream changes.
You can’t that’s would invalidate the description of the stream status topic, it sends data when it the stream changes.
Use timestamp comparison.
A webhook payload is a direct representation of the Helix endpoint of the same URL.
You subscribe to https://api.twitch.tv/helix/streams?user_id=foo when Twitch sends a webhook for that topic, then the helix response for that topic will be the same as what you just got POSTed, so there shouldn’t be such a condition.
And in my experience I’ve not seen this as most of my systems, use webhooks but still do backup helix/kraken long polls to compare and I’ve not seen a mismatch of what the webhook sends and my helix cache of the same topic.
Well you need the stream_id in order to account for the user renaming their twitch account. And ID’s are better overall for lookups to avoid snafu’s if users change their names.
But for me I usually have been oAuth authenticate before I start a (webhook) subscription, so I have their UserID in the response to authentication.
The last part (“get stream for id”) I mean to get the stream for a specific ID, not the the ID of a user to make the hook. I mean, when I create the hook, I want to know the current status, so I have to do another query to know the actual status.
Actually, is not the first time that I’ve seen a “give me the current status when I create the subscription” instead of doing two different API calls. Subscriptions are meant to update the status depending on a given starting status, so I guess that is primordial to at least receive the starting status without doing extra calls.
And with kraken, I’ve seen the “receive alternate online/offline” in subsequent API calls (not using hooks) until some minutes has passed. Maybe helix don’t has the same cache rules.
Timestamp comparison could work, but, if the webhook has the state “stream started” before I subscribe (so I will not get that he is online) and the API endpoint still don’t has the cache for stream started? I’ll get a null stream from the endpoint and also won’t get a “stream started” event from the hook.
A webhook payload sends the same data as the helix endpoint. So if you get a hook and immediately fetch the topic then the content should match the hook data you just go.
It shouldn’t happen but I’ll agree it’s a edge case.
For such a scenario, do a helix fetch every 5 minutes after creating the new subscription for a brand new user should cover it. Or thats what I would do.