feat(jobs): jobs describe themselves — description, mutates, repair_description

The admin panel had no repair toggle wired to anything but a hardcoded
name list naming the two refcount tenants, so `thumb_derived_import` and
`thumb_attached_import` could not be run in repair mode from the UI at
all despite supporting it. And nothing in the job list said what any
given job does or whether clicking Run on production writes anything.

Three defaulted methods on `JobHandler` and `RecoverableJobHandler`:

    fn description(&self) -> &'static str
    fn mutates(&self) -> Mutates          // Never | Always | OnRepairOnly
    fn repair_description(&self) -> Option<&'static str>

`RecoverableAdapter` forwards them — the registry only holds
`dyn JobHandler`, so a tenant's metadata is invisible otherwise, and
falling back to the defaults would report every recoverable job as
read-only, including the ones that delete files.

Three values rather than a boolean because a job can be read-only by
default and destructive under `?repair=true`; a boolean answers wrongly
for one of its two modes, and `false` on something that unlinks files is
the dangerous direction to be wrong in. `repair_description` returning
`Option` collapses "does it repair" and "what does repair do" into one
method: presence gates the toggle, content is the confirmation text —
which the frontend cannot invent, since correcting a counter and
deleting sidecars are not the same warning.

`OnRepairOnly` with no `repair_description` is rejected at registration:
it claims to mutate only under a flag it does not support.

All 17 registered jobs declare all three. The panel now renders the
description under each name, badges read-only jobs, confirms before a
plain run of a mutating one, and offers the repair variant off the
backend flag instead of the name list.

Descriptions are English in the trait, next to the behaviour: one in
`locales/*.json` rots invisibly the moment a job changes, and a
translator cannot know what `manifests_consistency` reconciles. i18n can
layer on later keyed by job name with these as the fallback.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Edouard Vanbelle
2026-08-29 00:04:12 +02:00
parent b485db46fa
commit 1ea3826660
27 changed files with 906 additions and 134 deletions
@@ -46,8 +46,8 @@ use uuid::Uuid;
use crate::application::ports::thumbnail_ports::ThumbnailSize;
use crate::infrastructure::scheduler::{
JobRegistry, JobRunArgs, JobStore, JobStoreProvider, RecoverableJobHandler, RunOutcome,
RunStatus, record_or_log,
JobRegistry, JobRunArgs, JobStore, JobStoreProvider, Mutates, RecoverableJobHandler,
RunOutcome, RunStatus, record_or_log,
};
use crate::infrastructure::services::dedup_service::DedupService;
// The readback-then-unlink rule is shared, not copied: two versions of it
@@ -167,6 +167,28 @@ impl RecoverableJobHandler for ThumbAttachedImport {
THUMB_ATTACHED_IMPORT_JOB_NAME
}
fn description(&self) -> &'static str {
"Migrates USER-UPLOADED previews (ext-{file_id}.jpg) into \
file-keyed blob storage. Until a row exists, copying a file loses \
its preview: the sidecar is keyed by file id and no copy path \
duplicates it. These bytes have no server-side render path, so \
unlike rendered thumbnails they cannot be regenerated."
}
fn mutates(&self) -> Mutates {
Mutates::Always
}
fn repair_description(&self) -> Option<&'static str> {
Some(
"Also DELETES each sidecar once its replacement has been read \
back. Previews whose file no longer exists are deleted without \
a readback — nothing can reference them again. Irreversible, \
and these bytes cannot be regenerated, so the readback is the \
only safeguard.",
)
}
async fn count_total(&self) -> Option<u64> {
let mut total = 0u64;
for size in ThumbnailSize::all() {
@@ -308,10 +330,12 @@ impl RecoverableJobHandler for ThumbAttachedImport {
// there is no row and no blob to read back, and nothing to
// regenerate from either.
orphaned += 1;
let mut removed = false;
if delete_imported {
let path = self.thumbnails_root.join(&dir_name).join(&name);
if fs::remove_file(&path).await.is_ok() {
deleted += 1;
removed = true;
// Explicit: nothing to verify against, so this
// bypasses verify_and_unlink. Worth auditing
// loudest of all — these bytes were
@@ -325,22 +349,35 @@ impl RecoverableJobHandler for ThumbAttachedImport {
&path,
);
}
} else {
record_or_log(
store,
THUMB_ATTACHED_IMPORT_JOB_NAME,
"attached_sidecar_orphan",
"anomaly",
None,
serde_json::json!({
"path": position,
"file_id": file_id_str,
"note": "no storage.files row; unimportable, and deleted on a \
repair run since nothing can reference it again",
}),
)
.await;
}
// Recorded in BOTH modes — see the twin in
// thumb_derived_import. Deleting a non-regenerable
// user-uploaded preview and reporting nothing is the
// worst version of this: the one outcome an operator
// needs in the run drawer was the one it withheld.
record_or_log(
store,
THUMB_ATTACHED_IMPORT_JOB_NAME,
"attached_sidecar_orphan",
// `anomaly` renders as "notices"; `detail.deleted`
// is what says whether the run acted. See the
// derived twin.
"anomaly",
None,
serde_json::json!({
"path": position,
"file_id": file_id_str,
"deleted": removed,
"note": if removed {
"no storage.files row; sidecar was unimportable and has been \
deleted — nothing can reference it again"
} else {
"no storage.files row; unimportable, and deleted on a repair \
run since nothing can reference it again"
},
}),
)
.await;
} else {
let path = self.thumbnails_root.join(&dir_name).join(&name);
match fs::read(&path).await {
@@ -458,7 +495,16 @@ impl RecoverableJobHandler for ThumbAttachedImport {
{unverified} kept unverified"
);
RunOutcome::completed()
// Same reasoning as the derived twin: what the run did belongs on
// the run row, not only in the process log.
RunOutcome::completed_with(serde_json::json!({
"imported": imported,
"already_present": already,
"deleted": deleted,
"unverified": unverified,
"orphaned": orphaned,
"failed": failed,
}))
}
}