Repository navigation
bug(scheduler): _execute_process_schedule lock-denial branch still unaudited (sibling of #1969) #1994
Description
#1975 fixed the agent-schedule path: a cron tick suppressed by the Redis distributed lock now writes a skipped execution row. The identical bare-return lock-denial branch survives in _execute_process_schedule (src/scheduler/service.py ~2138–2141) — a denied process-schedule tick still leaves no audit record. Same one-call fix shape as #1975; out of #1969's explicit scope (agent schedules), filed as follow-up.
Activity
dolho commentedon Aug 6, 2026
/claim — taking this. Will mirror the #1975 shape onto the process-schedule branch.
github-actions commentedon Aug 6, 2026
@dolho This issue is already assigned to dolho. Use
/unclaimfirst if you want to take over.dolho commentedon Aug 6, 2026
PR up: #2039
Mirrored the #1975 shape onto
_execute_process_schedule. One thing the issue's "same one-call fix" framing understates:_record_skipped_process_schedulehard-coded the max_instances wording, so a bare call would have filed the lock collision under the wrong mechanism. Addedskip_reason/event_reasonthe way #1808 did for the agent-schedule sibling, with defaults preserving the existingEVENT_JOB_MAX_INSTANCEScaller's behaviour (pinned by a test).14 tests mirroring
test_1969_lock_denied_tick_audit.pyso the two paths stay reviewable side by side, including an end-to-end case that lands a realskippedrow in SQLite rather than only asserting the helper was called. Mutation check: revertingservice.pyfails 6 of 14.fix(scheduler): audit a lock-denied process-schedule tick (#1994) (#2039