mirror of
https://github.com/jhd3197/ServerKit.git
synced 2026-11-09 05:24:49 +09:00
Juan DenisandClaude Opus 5
07dbffbedc
Plan 72 item A.1. The backup_drill_stale and backup_unverified checks both emitted repairable: True, but DoctorService.repair() only knew drift, service, dns and extension. Every Repair button those checks rendered came back "Unknown repair kind: backup_drill" -- a button that failed 100% of the time, on the check family whose entire job is telling you whether your backups can be trusted. The dispatcher now handles both, and they are deliberately asymmetric because the underlying services are. request_drill enqueues a backup.drill.run job, so that answer carries the job id for the console to link to. verify_run does the size and checksum comparison inline and returns a verdict, so there is no job id -- claiming one would send the console looking for a job that does not exist. The plan assumed both enqueued; only the drill does. Verification finding a BAD copy is reported as a failure, not a fix. It is a worse outcome than "unverified" and calling it a successful repair would be a lie told by a green checkmark. Both branches turn their services' ordinary refusals -- a drill already in flight, no successful backup to drill, backup not found -- into plain error text rather than letting them escape, and a policy_id echoed back for a since-deleted policy reads as gone instead of raising. The second half is the same defect from the other side. verify_run compares against the REMOTE copy and raises when there is none, so a local-only backup was rendering a Repair button that could never succeed. That check now only offers the button when there is something to verify against, and otherwise says what would actually fix it: send the policy offsite, or run a restore drill. Drills started this way are attributed to 'doctor' rather than 'manual', so the drill history says where they came from -- the field is free-form and only displayed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>