Three dispatch sites pin a deterministic jobId. `queue.add` with an existing
custom jobId returns the existing job rather than throwing, so any retained
terminal record makes later dispatches a silent no-op while still reporting
success to the caller.
- download_model_job: only `failed` records were cleared, so once a model
downloaded successfully its retained completed job blocked every later
request for that model. Deleting the model and reinstalling it did nothing,
and a restart did not help because the record is persisted in Redis. Adds
getActiveByModelName, mirroring RunDownloadJob.getActiveByUrl.
- download_service.retryFailedJob: the model branch dispatched before removing,
so remove() targeted the job just enqueued under the same id instead of the
old record. Flipped to remove-then-dispatch, matching the file branch.
- embed_file_job: a retained failed record made re-indexing that file a no-op,
returning 202 "Indexing queued" with nothing enqueued.
In-flight jobs are still returned as-is, so re-clicking during an active
download or embed stays idempotent.
Diagnosis by @caweis in #1214, including the retry-ordering race and the embed
case. Reimplemented in-house rather than ported, as noted there.
Closes#1214
5c1ea23b81