fix: worker's reclaim-stale-jobs commit was gated on the wrong count
_process_one's poll loop called reclaim_stale_jobs() but only committed when its return value (count of jobs reset to 'pending') was truthy. MWP9's reclaim_stale_jobs fix added a second UPDATE -- terminally failing exhausted stale jobs -- without changing that return value, so whenever the only stale rows were exhausted ones, the commit was skipped entirely and the 'failed' UPDATE was silently rolled back on session close.
Confirmed live on staging: after deploying the MWP9 reclaim fix, the worker logged '❌ Terminally failed 2 exhausted stale job(s)...' on every single 1s poll cycle, forever, for the identical two job IDs -- the clearest possible signature of an update that runs but never persists.
Fix: commit unconditionally after reclaim_stale_jobs. It's two UPDATE statements with narrow WHERE clauses; committing an empty transaction when neither matches is free.
Semantic Changes
1 symbol
Files Changed
~1
1084 in snapshot
0 comments
muse hub commit comment sha256:743e3346e49f299132ca3e46eb44c086c29c38cee18fc21dab892e6815f38b43 --body "your comment"
No comments yet. Be the first to start the discussion.