[Feature Request] Mark request as failed/unsent if fails to be sent to Radarr/Sonarr

[zwimer]

Description

Right now, if a user makes a request when Jellyseerr cannot connect to Radarr/Sonarr, because of network issues or because Radarr/Sonarr are down, that request is stuck forever. Jellyseerr retains the request, but since it was never received by Radarr/Sonarr they won't act on it. Jellyseerr does not seem to attempt to resend the request Radarr/Sonarr at a later date and acts as if the request was received. Fixing this issue can easily be mitigated by #2052 however, identifying this issue requires manual effort. External users who make requests that silently fail will never know, and these requests may remain undiscovered until they both remember the request when they know the media is available and tell the admin about missing media.

Desired Behavior

If Jellyseerr cannot connect to Radarr/Sonarr to make the request, note this is the GUI somehow- mark it as failed, mention a 404 was returned, or something that lets the user know the request wasn't fully propagated. Importantly, Jellyseerr should not stay silent about this.

Additional Context

Initial proposal to mitigate this problem was 'Auto re-request on failure', this was denied: #1994 (comment)

Code of Conduct

• I agree to follow Seerr's Code of Conduct

[zwimer]

Ideally Jellyseerr could even use the notification system to alert either admin or the user of the issue. Something like "This request may not have been successfully sent to Radarr/Sonarr."

[gauthier-th]

Or we could just mark the request as "Failed" when a Radarr/Sonarr instance exists but is misconfigured or unreachable.
This should solve both your issue and remove the need for the retry button.
@fallenbagel wdyt?

[zwimer]

Or we could just mark the request as "Failed" when a Radarr/Sonarr instance exists but is misconfigured or unreachable. This should solve both your issue and remove the need for the retry button. @fallenbagel wdyt?

I assume that if this occurs, notifications will also trigger in the same way they will upon the request being marked as completed? If so, I think that is an acceptable solution.

[0xSysR3ll]

Or we could just mark the request as "Failed" when a Radarr/Sonarr instance exists but is misconfigured or unreachable. This should solve both your issue and remove the need for the retry button. @fallenbagel wdyt?

I've just implemented this, and it's working well. Interestingly, I wasn't aware that a native retry button already existed ?

I assume that if this occurs, notifications will also trigger in the same way they will upon the request being marked as completed? If so, I think that is an acceptable solution.

Yes it will.

[gauthier-th]

I wasn't aware that a native retry button already existed ?

The retry button was only appearing when Radarr/Sonarr received the request with the new item, but failed to add it to Radarr/Sonarr (e.g. because of a network issue or a file permission issue)

[bendschs]

my radarr and sonarr instances only run for a couple of hours at night every day due to their rather high amount of memory consumption (running the setup on a small embedded device with limited memory). i think the best way to handle this, would be to let jellyseer periodically retry failed attempts.

[ryanovas]

Sometimes things go down and having a clear indication that jellyseer was unable to communicate with Radarr/Sonarr with a retry button is a huge QOL fix I would say

[fallenbagel]

Sometimes things go down and having a clear indication that jellyseer was unable to communicate with Radarr/Sonarr with a retry button is a huge QOL fix I would say

Thats already fixed in this pr:
#2171