So there's been a change to the way interaction responses are handled which causes some issues with the error reporting.
If we attempt to create a new response and there's already an existing response the following is returned:
parrot | thread 'tokio-runtime-worker' panicked at 'failed to create response: Serenity(Http(UnsuccessfulRequest(ErrorResponse { status_code: 400, url: Url { [TRUNCATED] }, error: DiscordJsonError { code: 40060, message: "Interaction has already been acknowledged.", errors: [] } })))', src/handlers/serenity.rs:373:14
It's an easy fix, but I figured I would ask how we'd like to address it:
A) Clobber the old response with the new one
B) Create a followup message when creating the initial response fails
Unfortunately I don't know of a clean way to implement this with the current error handling built into the create_embed_response at the moment.
🪜 Reproduction Steps
Play a video that has been privated or has been deleted (https://www.youtube.com/watch?v=cwFQpRTwaP0 for example
The application will respond indicating that it is searching
yt-dlp will throw an error since the video is inaccessible
The application will attempt to respond with an error but will fail because the initial response still exists
📝 Description
So there's been a change to the way interaction responses are handled which causes some issues with the error reporting. If we attempt to create a new response and there's already an existing response the following is returned:
It's an easy fix, but I figured I would ask how we'd like to address it: A) Clobber the old response with the new one B) Create a followup message when creating the initial response fails
Unfortunately I don't know of a clean way to implement this with the current error handling built into the create_embed_response at the moment.
🪜 Reproduction Steps
https://www.youtube.com/watch?v=cwFQpRTwaP0for exampleℹ Environment / Computer Info
mainArch Linux📸 Screenshots
No response