Readarr 404 on stale queue item crashes decluttarr instead of skipping the item

[tomerh2001]

Summary

Decluttarr exits when a Readarr queue item references a bookId that no longer exists in Readarr.

In my case, the queue still contained a completed item with bookId=198, but GET /api/v1/book/198 returned 404 Not Found. Decluttarr then crashed during remove_unmonitored instead of skipping that stale item and continuing with the rest of the configured jobs.

Environment

• image: ghcr.io/manimatter/decluttarr:latest
• image digest: sha256:1e93192e9477cb01591de2ddac12d503662e2659792448e811b74bdb58e07ae4
• Readarr was otherwise healthy and reachable
• remove_unmonitored was enabled
• readarr was configured under instances

What happened

Readarr queue contained a completed item similar to this:

• queue item id: 1684540719
• bookId: 198
• state: completed
• tracked download state: importFailed

But querying the book endpoint for that queue item's bookId returned 404:

GET /api/v1/book/198 -> 404 Not Found

Decluttarr then exited with this traceback:

ERROR   | HTTP error occurred: 404 Client Error: Not Found for url: http://readarr:8787/api/v1/book/198
Traceback (most recent call last):
  File "/app/main.py", line 67, in main
    await job_manager.run_jobs(arr)
  File "/app/src/job_manager.py", line 27, in run_jobs
    await self.removal_jobs()
  File "/app/src/job_manager.py", line 83, in removal_jobs
    items_detected += await removal_job.run()
  File "/app/src/jobs/removal_job.py", line 46, in run
    self.affected_items = await self._find_affected_items()
  File "/app/src/jobs/remove_unmonitored.py", line 13, in _find_affected_items
    if detail_item_id is None or await self.arr.is_monitored(detail_item_id):
  File "/app/src/settings/_instances.py", line 348, in is_monitored
    response = await make_request("get", endpoint, self.settings, headers=headers)
  File "/app/src/utils/common.py", line 79, in make_request
    response.raise_for_status()
requests.exceptions.HTTPError: 404 Client Error: Not Found for url: http://readarr:8787/api/v1/book/198

Because the process exits, a containerized deployment enters a restart loop.

Expected behavior

A stale Readarr queue item should not take down the entire Decluttarr process.

At minimum, I would expect Decluttarr to:

• catch the 404 for that one missing bookId
• log a warning about the stale queue item
• skip that item and continue processing other jobs / other instances

It may also make sense to treat it as an orphaned or stale queue record, but the important part is that the process should not exit.

Reproduction idea

1. Configure Decluttarr with a Readarr instance and enable remove_unmonitored.
2. Have Readarr return a queue item whose bookId no longer exists at /api/v1/book/<id>.
3. Run Decluttarr.
4. When it reaches the Readarr pass, it crashes on the unhandled 404.

Temporary workaround

The quickest local stabilization was to temporarily remove or disable the Readarr instance from Decluttarr's config and restart the container, for example:

instances:
  readarr: []

That allows Decluttarr to continue running Sonarr/Radarr/Lidarr jobs until the stale Readarr queue item is handled separately.

Notes

This might start with inconsistent state from Readarr itself, but even if that is the upstream cause, it would still be helpful for Decluttarr to handle the 404 defensively so one bad queue record cannot crash the whole service.