twitchdev / issues

Issue tracker for third party developers.
Apache License 2.0
73 stars 6 forks source link

"users/blocks" service corruption - episode 2 #787

Closed Durss closed 1 year ago

Durss commented 1 year ago

Brief description Basically the same as what's described on this previously fixed issue, but it's crashing again https://github.com/twitchdev/issues/issues/639

How to reproduce Call the endpoint helix/users/blocks in PUT with target_user_id=blablabla. (i get a 200 as if everything went fine) Call the endpoint helix/users/blocks in GET, you'll get a 500. To make the service back we need to call the endpoint with DELETE method and the exact same wrong target_user_id provided before. Only then the GET endpoint will work again. If, like I, you forgot which wrong data you sent before, you basically cannot get the service working back.

Query example that corrupts the service

fetch("https://api.twitch.tv/helix/users/blocks?target_user_id=427acf39-21dc-4a5f-b6dd-bbfd5456a41d", {
  "headers": {
    "authorization": "Bearer {BEARER_TOKEN}",
    "client-id": "{YOUR_CLIENT_ID}",
    "content-type": "application/json",
  },
  "body": null,
  "method": "PUT",
});

Expected behavior Calling the endpoint with a wrong user ID should yield an error.

Screenshots

Additional context or questions

Durss commented 1 year ago

If that can be of any interest, i no longer have a 500 when calling the GET users/blocks endpoint.

brian6932 commented 1 year ago

I am no longer getting this either, seems like it's fixed

Durss commented 1 year ago

I made some tests trying to block wrong user IDs, the PUT service returns a 204 like everything went OK which doesn't feel right, but the GET endpoint isn't corrupted anymore after that.

Documentation does not specify what the HTTPS status response should be if the target_user_id isn't valid so technically, even though I believe it would make sense to return a 400, it works the expected way.