Skip to content

Feature request: periodically re-process stale pending Seerr requests #27

Description

@Sorilo

Hello and thanks for the work on the service! Redirecterr has been working well for routing my Seerr requests between normal and anime Radarr/Sonarr instances.

I ran into one situation where several requests stayed Pending in Seerr, presumably because the original Request Pending Approval webhook was missed while Redirecterr was unavailable/restarting. I believe the redirecterr service was down/offline for a time while seerr requested a few pieces of content.

Would it make sense to add an optional periodic reconciliation scan for stale pending requests (ideally one that could be configured in the yaml)?

My thought would be:

Query Seerr for requests where filter=pending
Ignore very recent requests so the normal webhook path gets first chance
For requests older than a configurable age, run them through the same routing/filter logic Redirecterr normally uses
Apply the appropriate destination instance/root/profile
Approve them if they are still Pending

Something roughly configurable like:

pending_scan_enabled: true
pending_scan_interval: 60m
pending_scan_min_age: 5m

The goal would just be self-healing if a webhook is ever missed, without changing the normal webhook-first behavior.

For example:

Normal:
Seerr request → Pending webhook → Redirecterr → route + approve

Recovery:
periodic pending scan → stale pending request → Redirecterr routing logic → route + approve

Ideally it would re-check that the request is still Pending immediately before acting so the process is safe/idempotent.

My use case is multiple Radarr/Sonarr instances with Redirecterr choosing between normal, 4k, and anime destinations and this seems like it would be a relatively simple feature request that would add some self-healing capability to the service for cases where there are pending requests in Seerr.

Thanks again for your work opening this up to everyone and for the work you do!

No urgency — just thought this might be a useful reliability feature.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions