fix(downloads): make retry-import actually requeue the import

[m4bard]

POST /api/v1/downloads/{id}/retry-import answers 200 with "Import retry queued" and logs Reset blocked import ... back to ImportPending. It queues nothing.

I hit this trying to retry a blocked import. The call succeeded and the status changed, but no DownloadProcessingJobs row ever appeared for that download. I gave it fifteen minutes, then restarted the container in case a fresh processor would pick it up, and it stayed where it was.

Why

RetryBlockedImport calls download.Unblock() and saves the row. That clears ImportBlockReason and sets the status to ImportPending. Nothing watches either field.

The only thing that imports a download is a DownloadProcessingJob, and two places in production create one: DirectDownloadProcessor for DDL, and DownloadMonitorService.OnDownloadCompleted. The second is reached from TriggerCallbacks, which switches on (previous.Status, current.Status) and returns as soon as they match:

case var (old, next) when old == next:
    return;

So the enqueue is edge-triggered on the download client reporting completion. For an import that is already blocked, that edge is in the past and will not come round again. The row sits in ImportPending while the endpoint reports success.

The button

The Retry button in the downloads view is the same feature approached from the other side:

const retryDownload = async () => {
  toast.info('Coming Soon', 'Retry functionality will be implemented soon')
}

It never called the endpoint. It also rendered on download.status === 'Failed', and the endpoint answers 400 to anything that is not ImportBlocked, so pointing the stub at the endpoint would not have been enough by itself. The button could not appear for a state the endpoint accepts.

Between the two, there is currently no working way to retry a blocked import by any route. #890 is someone sitting in that state.

What this changes

Adds IDownloadProcessingJobService.RequeueAsync. I made it separate from EnqueueAsync rather than loosening that one, because they are driven by different things: EnqueueAsync runs off the client reporting completion and so requires the download to be Completed, while a retry arrives later, once the download is already ImportPending.

RequeueAsync returns an existing active job if there is one. Failing that it reuses the download's newest job, and failing that it creates a fresh one, since retention deletes terminal jobs after a week. Reusing keeps the processing log, which is the only record of why the earlier attempts failed. It does reset the retry budget, on the grounds that someone asking for another attempt has usually changed something the job depends on. The recent-completion cooldown that EnqueueAsync applies is deliberately left off, since silently doing nothing is the behaviour being fixed.

The controller queues before it persists the unblock. If the queue call fails, the download stays blocked rather than landing in a state that reads as retrying and never is.

The button now calls the endpoint, and is offered on ImportBlocked.

Tests

RetryBlockedImport_ImportBlocked_TransitionsToImportPending asserted the status transition and nothing else, so it passed against an endpoint that did no work. I left it alone and added a second test beside it that asserts a job is actually queued.

Five tests added on the backend and two on the frontend. I checked that each one is capable of failing, by reverting the production changes one at a time: the controller requeue, the job reuse, the retry-budget reset, and both halves of the frontend change. Each time the matching test failed and the rest stayed green.

Full suite passes.

---

Worked through with Claude Code at my direction. The claims above were checked by running them rather than by reading, and I reviewed this before posting.

[m4bard]

Amended and force pushed, now eb553b9a. One addition, and it is worth explaining rather than leaving in the diff.

retry-import now also accepts a download sitting in ImportPending when nothing has an active job for it.

That state is this endpoint's own doing. Before the change in this PR it cleared the block and set ImportPending, then queued nothing, so every call left a download that no job will ever pick up. Gating strictly on ImportBlocked, which is what I had, refuses exactly those downloads and leaves them stuck for good.

They are also worse off than blocked ones, which I had not appreciated when I opened this:

• AutomaticSearchService.cs:156 counts ImportPending as an active download and skips the audiobook.
• DownloadDuplicateGuard.cs:39 does the same.
• Neither mentions ImportBlocked.

So a download the old endpoint touched is not merely unimportable. The book stops being searched as well, silently, because something looks like it is already downloading it. A blocked download at least leaves the book eligible.

The active job check is what keeps this narrow. An import genuinely in flight has a pending or processing job and is still refused, so this is not "accept anything that is not blocked". Two tests cover it, and the second is there so the pair cannot both pass against a version that simply accepted every ImportPending.

Nothing else in the PR changed.

---

Worked through with Claude Code at my direction. The claims above were checked by running them rather than by reading, and I reviewed this before posting.