twitchdev / issues

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

Get Streams endpoint misbehaves in certain conditions with `user_login` query parameter #700

Open CloudburstSys opened 1 year ago

CloudburstSys commented 1 year ago

Brief description The Get Streams endpoint (/helix/streams) throws an undocumented 400 Bad Request when attempting to query a user that no longer exists via the user_login query parameter, specifically complaining about "Malformed query param". This does not occur with the user_id query parameter, which returns an empty data array when querying a user that no longer exists (e.g. -1).

How to reproduce Query the Twitch API on the /helix/streams endpoint with the user_login parameter set to a non-existent user (commanderstarcat is confirmed not to exist, so this value can be used).

Expected behavior The API will respond with a HTTP 200 response code with an empty data array, just like querying with the user_id parameter set to a non-existent user.

Screenshots Querying an existing user with user_login: image

Querying a non-existent user with user_login (issue here): image

Querying a non-existent user with user_id: image

Additional context or questions The solution for this is likely one of these 3 options:

thedist commented 1 year ago

Make this situation behave as expected, returning an empty data array instead of a 400 response code (preferred).

I believe this is the ideal solution, much like Get Users where if a user doesn't exist then they just aren't included in the results, which still lets a partial success if multiple users are in the params.

Deprecate the user_login query parameter entirely, as it's main use is for programmers who can't be bothered to make sure the user even exists before looking for streams, which can be considered bad practice.

Strongly disagree with this. That'd be a breaking change, it's something people had asked for, and if there are usecases/situations where an app may only be provided with a user_login it could be more performant to just go straight to Get Streams without using Get Users first if that user info isn't useful to the app.

CloudburstSys commented 1 year ago

Strongly disagree with this. That'd be a breaking change, it's something people had asked for, and if there are usecases/situations where an app may only be provided with a user_login it could be more performant to just go straight to Get Streams without using Get Users first if that user info isn't useful to the app.

That's why it's at the bottom of the list, it's a solution.. but it's the most laziest solution which is just a bad idea in general. But since it is a solution I listed it. I have updated the original issue to outline that it's not a good idea

danthegoodman1 commented 1 year ago

For renames, it would be really great if it would redirect to the new name!

thedist commented 1 year ago

For renames, it would be really great if it would redirect to the new name!

Feature requests should go to UserVoice https://twitch.uservoice.com/forums/310213-developers/. That being said though, I disagree that the Get Streams endpoint should have any sort of redirects for users who have changed name. If you want to always have stream data for a specific user you should make requests using their user_id as that persists through username changes. Additionally, it's possible for a username that is reserved after a name change to eventually be released and so it would lead to a poor user experience if requests for a user who changed their name get results for their new name one day, and then the next get results for someone completely different who just happened to register that old name.

danthegoodman1 commented 1 year ago

fair enough!

On Fri, Mar 10, 2023 at 10:06 AM Jeff Martin @.***> wrote:

For renames, it would be really great if it would redirect to the new name!

Feature requests should go to UserVoice https://twitch.uservoice.com/forums/310213-developers/. That being said though, I disagree that the Get Streams endpoint should have any sort of redirects for users who have changed name. If you want to always have stream data for a specific user you should make requests using their user_id as that persists through username changes. Additionally, it's possible for a username that is reserved after a name change to eventually be released and so it would lead to a poor user experience if requests for a user who changed their name get results for their new name one day, and then the next get results for someone completely different who just happened to register that old name.

— Reply to this email directly, view it on GitHub https://github.com/twitchdev/issues/issues/700#issuecomment-1463936943, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEH3JLB4W42ZYG5K4PDZ3ZDW3M7PHANCNFSM6AAAAAASW3FZ5U . You are receiving this because you are subscribed to this thread.Message ID: @.***>

rbroggi commented 1 week ago

I just wanted to :+1: this issue, we also thought the behaviour surprising (as also not expected).

rbroggi commented 1 week ago

please vote up!

https://twitch.uservoice.com/forums/310213-developers/suggestions/49039022-fix-get-streams-usage-with-user-login

thedist commented 1 week ago

please vote up!

https://twitch.uservoice.com/forums/310213-developers/suggestions/49039022-fix-get-streams-usage-with-user-login

UserVoice is for feature requests, not for requesting bugs to be fixed as that's what this repo is for.