-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Avoid error on empty requests #223
Comments
the url we call for get_users::GetUsersRequest::builder()
.id(vec![])
.login(vec![])
.build(); would be calling this is special-cased by twitch, where it returns the current user. For me for example I'm not sure I understand the issue here. Where is the error? |
This is interesting, it seems the behavior is different in the browser. Probably because you have some form of cookie? use twitch_api2::{twitch_oauth2::AppAccessToken, TwitchClient};
#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
let client_id = std::env::var("TWITCH_CLIENT_ID").unwrap().into();
let client_secret = std::env::var("TWITCH_CLIENT_SECRET").unwrap().into();
let client: TwitchClient<reqwest::Client> = TwitchClient::default();
let token = AppAccessToken::get_app_access_token(&client, client_id, client_secret, vec![])
.await
.unwrap();
let req = twitch_api2::helix::users::get_users::GetUsersRequest::builder()
.id(vec![])
.login(vec![])
.build();
let resp = client.helix.req_get(req, &token).await;
dbg!(&resp);
resp.expect("valid response");
Ok(())
} This gives:
I'm using |
Aha, no default user associated with apptokens so twitch throws an error on empty query. There are no differences with using a browser, I jus have an addon setting the correct headers, using an user token. I dont think it's possible or usable for twitch_api2 to catch this kind of error without speaking to twitch. |
Oh right. Might be worth mentioning this in the doc of |
While using the crate, I noticed some requests will be rejected by twitch because empty. For example:
will be rejected. But in this case, the response will be empty. Would it be desirable to bypass the entire call and immediately returns a response in this case?
Or, looking at the
RequestGet
trait, it seems maybe it would be better to detect this error when parsing the response and recover?What do you think?
The text was updated successfully, but these errors were encountered: