Skip to content
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

Spotify source has issues if service is ran for an extended duration #211

Open
StaticRocket opened this issue Oct 31, 2022 · 13 comments
Open
Labels
🐛 bug Something isn't working

Comments

@StaticRocket
Copy link
Contributor

📝 Description

The Spotify source has issues looking up queries after the service has been running for a few days. I believe this is related to the auth routine but I haven't had time to properly debug this yet.

This may straight up be a byproduct of me running this on a machine without ECC memory, but it seems a little too consistent for that.

🪜 Reproduction Steps

  1. Leave parrot running for a few days
  2. Attempt to play something from Spotify
  3. Response will be failed to fetch track

ℹ Environment / Computer Info

  • Parrot version: main
  • Operating System: archlinux

📸 Screenshots

No response

@StaticRocket StaticRocket added the 👓 triage This issue is being reviewed label Oct 31, 2022
@aquelemiguel
Copy link
Owner

I haven't been able to properly debug it either, but it's also happening on our deploy:

thread 'tokio-runtime-worker' panicked at 'failed to create response: Serenity(Http(UnsuccessfulRequest(ErrorResponse { status_code: 404, url: Url { scheme: "https", cannot_be_a_base: false, username: "", password: None, host: Some(Domain("discord.com")), port: None, path: "/api/v9/interactions/1036673658422313000/aW50ZXJhY3Rpb246MTAzNjY3MzY1ODQyMjMxMzAwMDpIZTM2N3A3QWkzazZESmdHOHNBdXZ5eGRTcVlQMTlEZ21QYjFQNlpHbzE1dENvUnZjckt4S3RidmxiYlNsOVFLNmJuUm1pVU5RSU1DTmxEOFBTWVNFYWRTVVEyRjJwSFIxUDJxcVEwWlIyWFVGNmtIWEkyejNOZTFGY1U1VGhHYw/callback", query: None, fragment: None }, error: DiscordJsonError { code: 10062, message: "Unknown interaction", errors: [] } })))', src/handlers/serenity.rs:462:18

@aquelemiguel aquelemiguel added 🐛 bug Something isn't working and removed 👓 triage This issue is being reviewed labels Nov 8, 2022
@StaticRocket
Copy link
Contributor Author

@aquelemiguel , that looks like a serenity error. From the error it looks like it may be trying to edit an interaction that doesn't exist. I wasn't getting the same error when I initially submitted this issue, but that doesn't mean it's not related...

@afonsojramos
Copy link
Collaborator

@aquelemiguel However, the deployed version is 1.4.2, which is a bit far from what we currently have. Let's release 1.4.3 soon and recheck.

@rafaeldamasceno
Copy link
Contributor

rafaeldamasceno commented Dec 28, 2022

This issue still occurs on 1.5.0, but perhaps the latest rspotify version has fixed it on main.

@blimp4242
Copy link

blimp4242 commented Feb 12, 2023

Still happens to me on 1.5.1, the error starts when the bot has been running for about an hour.
Could that be caused by the Spotify API token expiring after a certain time and not being refreshed?

@blimp4242
Copy link

I've maybe managed to find the issue, like i said before it probably has to do with the token expiring after a while (about 1hour for me).
I kind of implemented a jenky fix for now by requesting a new token when a spotify link is passed to the play command and it seems to work but i need more extensive testing to be sure.

Basically i simply added a new line of code to request a new token after this line:

let spotify = verify(spotify.as_ref(), ParrotError::Other(SPOTIFY_AUTH_FAILED))?;
+ spotify.request_token().await?;

I'm aware that that's no were near an efficient way of fixing the problem because it would request a new token each time you call the play command containing a spotify url but i have really little knowledge of Rust and im not capable of implementing a proper fix for now.

I'll keep you updated in the following days to let you know if the issue reoccurs or if it's fixed.

@afonsojramos
Copy link
Collaborator

afonsojramos commented Feb 12, 2023

@blimp4242 Actually, maybe that's actually what we're supposed to do! I'll do some investigating as well!

@afonsojramos
Copy link
Collaborator

@blimp4242 Yep, it seems that this is actually expected as Spotify Access Tokens do have an expiration time and will eventually become invalid.

The exact expiration time of the Token is specified in the "expires_in" field of the token response. But typically, the lifetime of a Spotify Token is one hour. So yeah, your quick fix is actually THE fix. Feel free to open the PR yourself, if not I can do it.

@joao-conde
Copy link
Collaborator

But we can't request a new token upon every new spotify search request. Instead, we need to wrap the get of the spotify object with a getter that provides the lock to it but also attempts some dummy operation to check if it is a valid token and then if it fails with an error indicating it expired, requests the new token and returns.

@afonsojramos
Copy link
Collaborator

Or you can just save when it will expire and request a new one on a new request if it has already expired.

@blimp4242
Copy link

@joao-conde Right, that's why i said it's a jenky implementation, do you want me to PR anyway?

@aquelemiguel
Copy link
Owner

Hi @blimp4242, firstly thank you for reporting and for the possible fix! ✌️

Regarding the PR, would you be willing to implement the fix as @joao-conde mentioned?
If not, there's no need to submit it, I can have a go at it. 😊

@blimp4242
Copy link

Thanks @aquelemiguel, im glad to help.
I'm kinda new to rust and programming in general so i think it will take me a while to implement it the right way, feel free to implement it yourself as you will surely do a better job and thanks again to everyone.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐛 bug Something isn't working
Projects
None yet
Development

No branches or pull requests

6 participants