I’m uncertain how to delete these existing event subs, is there any guidance on this issue? So far, this is preventing creating event subs. While I have recognized that creating a new sub each application run is unnecessary now, I’m in a state where I can no longer register these subscriptions as well as having multiple existing subscriptions for a single EventSub (from what I believe is an older version of this application). When attempting to create an EventSub, I’m given the response code of ‘Bad Request,’ which is most likely that this event sub already exists. I have not had issues with EventSub subscriptions for months until I saw there were duplicate EventSubs lingering.
using (
HttpClient httpClient = new()
)
{
httpClient.DefaultRequestHeaders.Add(
$"Authorization",
$"Bearer {TwitchData.AccountAccessToken}"
);
httpClient.DefaultRequestHeaders.Add(
$"Client-Id",
$"{TwitchData.ClientId}"
);
HttpResponseMessage httpResponse = await httpClient.GetAsync(
$"{c_urlAPI}/eventsub/subscriptions"
);
if (!httpResponse.IsSuccessStatusCode)
{
#if DEBUG
GD.PrintErr(
$"{nameof(TwitchManager)}.{nameof(UnregisterEventSubSubscriptions)}() - Web request GET failed with {httpResponse.StatusCode}."
);
#endif
return;
}
#if DEBUG
GD.Print(
$"{nameof(TwitchManager)}.{nameof(UnregisterEventSubSubscriptions)}() - Web request GET successful."
);
#endif
// successful pull of all existing responses
var twitchResponse = JsonConvert.DeserializeObject<TwitchResponseEventSubSubscriptions>(
await httpResponse.Content.ReadAsStringAsync()
);
// delete all existing event subscriptions
foreach (var data in twitchResponse.data)
{
httpResponse = await httpClient.DeleteAsync(
$"{c_urlAPI}/eventsub/subscriptions?id={data.id}"
);
if (!httpResponse.IsSuccessStatusCode)
{
#if DEBUG
// this is the failed status code of "Not Found"
GD.PrintErr(
$"{nameof(TwitchManager)}.{nameof(UnregisterEventSubSubscriptions)}() - Web request DELETE failed with {httpResponse.StatusCode}."
);
#endif
continue;
}
#if DEBUG
GD.Print(
$"{nameof(TwitchManager)}.{nameof(UnregisterEventSubSubscriptions)}() - Web request DELETE successful."
);
#endif
}
}
Running into the same problem. Lots of dangling websocket_disconnected-state subscriptions, returning 404 on delete. No code changes, broadcaster-level token access.
Websocket Disconnected don’t block creation of the same topics and will self disappear after an hour iirc (as in you do not need to delete these)
Only enabled subscriptions block additioanl subscriptions
So, only enabled subscriptions should be considered for deletion, anything else can be left to auto die (even if they are hanging around longer than they should)
let url = new URL('https://api.twitch.tv/helix/eventsub/subscriptions');
let params = {
first: 100,
status: 'enabled'
};
if (after) {
params.after = after;
}
url.search = new URLSearchParams(params).toString();
NOTE The GET API includes WebSocket subscriptions that were disabled within the last 1 hour only as compared to webhooks which returns disabled subsriptions for a maximum of up to 10 days.
Thanks for the report. The 404 issue when attempting to delete disabled WebSocket subscriptions is a known bug that should be fixed in the coming days. This shouldn’t impact your ability to create new EventSub subscriptions, since disabled subs do not count towards costs.
As far as the automatic expiry of disabled subs, this is performed on a best effort basis and may take longer than an hour.
This is likely unrelated to the above bug. What status code are you receiving? Disabled subs do not count as duplicates.
With respect to the bodies, all DELETE payloads only contain the following JSON information:
error=Not Found message=not found status=404
With respect to state of subscription, the only information I have that may be relevant is ‘status=websocket_disconnected’ for all received EventSubs from the GET request. From traces on Fiddler, I have not seen any particularly useful information that would otherwise give this information.
I believe this is a mistake on my end. I was able to resub after a few more attempts & they were not the same EventSubs. Each EventSub had a different timestamp than the previous after further investigation. My apologies.
The existing EventSubs were also removed later on. However, I do still receive the existing EventSubs as you described in the bug report, which I’ll ignore at this point. Is there any reason to send a DELETE on these if they are automatically cleaned up after X time? Previously, I was manually cleaning these up to remove the multiple subscriptions.
