rmancinasandClaude Opus 5
7797c45e9f
Ops jobs run as a child of the API process, so no job can outlive it. When a deploy landed 110 seconds into a REIMPORT, the child died and nothing was left to finalize the row — it stayed RUNNING forever. Because startJob() refuses to start while any RUNNING row exists, that one interrupted job wedged the panel permanently with no way out from the UI; recovering it took a manual UPDATE against the production database. A fresh boot is proof that nothing survived, so this is unconditional rather than filtered on age: "started recently" does not imply "still alive" here. Rows are updated one at a time rather than with updateMany so the reason can be APPENDED to the log. A job whose log simply stops mid-step with no explanation is what made the first occurrence hard to diagnose. Failure to reconcile is logged and swallowed: a wedged panel is bad, an API that will not boot is worse. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>