1.25.2 — Manual job retry publishes a runnable, linked replacement

2026-09-11

Retrying a failed, canceled or expired job now publishes a replacement with a fresh expiration and leaves the original as a terminal record linked to it. Before, an expired job's retry inherited its past deadline and expired before running, and the original was reset to pending with its diagnostics wiped. A second retry is refused while the replacement is still live.

Changed

• Manual retry (retry_request action, POST /api/jobs/retry, JobManager.retry_job, the assistant retry_job tool) publishes a replacement job and leaves the original untouched — its status, attempt count and error diagnostics are no longer reset to pending.
• The replacement's expiration is the larger of JOBS_DEFAULT_EXPIRES_SEC and the window the original was published with, extended by delay; the original's expires_at is never reused.
• Original and replacement reference each other: metadata.retried_as on the original, metadata.retried_from on the replacement, and new_job_id in the original's retry event.
• A second retry is refused with Job already retried as <id> while that replacement is pending, running or completed; allowed again once it has failed, been canceled or expired. This is double-submit protection, not a locked exactly-once guarantee.
• JobManager.retry_job accepts expired jobs and returns the replacement id (or False), matching the service path.
• A negative retry delay is refused instead of silently shortening the replacement's lifetime.
• A non-numeric delay sent through retry_request returns status: false instead of a 500.
• Removed JobActionsService.pause_job / resume_job — undocumented, unreferenced, and carrying the same reset-and-copy-expiry defect; cancel_job + retry_job cover the same need.

Fixed

• Retrying an expired job produced a replacement that expired before it ran.
• Retrying left the original row pending with its diagnostics erased — a zombie that a requeue_db_pending sweep would have executed a second time.
• A delayed retry longer than the default job lifetime expired before it was due.

Upgrade notes

• No migration. Code that detected "retry in flight" by watching the original job flip to pending should read metadata.retried_as instead — the original now stays failed / canceled / expired.