feat: simple failed request handling #474
Conversation
|
I just thought of one more thing. If someone deletes all requests associated with any media, we keep the media but set its status back to Unknown. That would mark it as failed, but it isn't. |
So the idea is that, if all requests are deleted with any media, it wouldn't matter if a request connected to it would be marked as failed, since there's no request to actually see as failed. However, when there are requests and the media is still unknown, that signifies it's failed since that shouldn't be a possible state when the media is in Radarr/Sonarr or available. |
Ah yeah true. Since there are no requests it won't show up in the request list so it doesn't really matter. |
johnpyp
force-pushed
the
feat/failed-request
branch
from
7fc48ee
to
5b545ea
Compare
|
One thing I didn't consider about setting to Pending and then back to Approved are the notifications there... might be better just to include a small refactor for a dedicated endpoint. |
The dedicated endpoint would just try to send the media back to radarr/sonarr again, yes? Because if we touch the statuses on the request it will still refire the listeners and trigger notifications. |
johnpyp
force-pushed
the
feat/failed-request
branch
2 times, most recently
from
6b91242
to
b0208ed
Compare
|
Yeah, so I added a
This is the same as the normal AfterUpdate hooks, with the exception of not sending notifications. Let me know if I should make this endpoint dedicated for retry instead, I figured it might be something that comes with more uses in the future, but you might prefer many overloads rather than a single endpoint. |
|
I think having its own endpoint is better. Right now you are setting an action in an endpoint that is supposed to accept a status. Even if its an overload, the docs will be clearer in that regard. |
johnpyp
force-pushed
the
feat/failed-request
branch
from
b0208ed
to
f6d7da5
Compare
johnpyp
force-pushed
the
feat/failed-request
branch
from
f6d7da5
to
1a0e6ad
Compare
src/components/StatusBadge/index.tsx
Outdated
| case MediaStatus.UNKNOWN: | ||
| return ( | ||
| <Badge badgeType="danger"> | ||
| {intl.formatMessage(globalMessages.failed)} | ||
| </Badge> | ||
| ); |
There was a problem hiding this comment.
This will cause the failed status badge to show up in many place throughout the app, not just the RequestList.
RequestCard uses this. So does the movie/tv details pages now.
|
|
||
| const messages = defineMessages({ | ||
| requestedby: 'Requested by {username}', | ||
| seasons: 'Seasons', | ||
| notavailable: 'N/A', | ||
| failedretry: 'Something went wrong retrying that request', |
There was a problem hiding this comment.
| failedretry: 'Something went wrong retrying that request', | |
| failedretry: 'Something went wrong retrying the request', |
When a movie or series is added with radarr or sonarr, if it fails, this changes the media state to unknown and sends a notification to admins. Client side this will look like a failed state along with a retry button that will delete the request and re-queue it.
johnpyp
force-pushed
the
feat/failed-request
branch
from
1a0e6ad
to
38dd491
Compare
|
🎉 This PR is included in version 1.14.0 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
Description
When a movie or series is added with radarr or sonarr, if it fails, this changes the media state to unknown and sends a notification to admins.
Client side this will look like a failed state along with a retry button, which when clicked will delete the request and re-add it.
Screenshot (if UI related)
Todos
yarn buildyarn i18n:extractIssues Fixed or Closed by this PR