RecurringTicketModel::claimForRun() intentionally advances next_run_atbeforeTicketModel::createTicket() runs (cron/create_recurring_tickets.php) — a deliberate design choice (per an existing code comment) to prevent duplicate-ticket floods if creation fails partway and the cron retries.
Impact of that tradeoff: if createTicket() then fails (DB blip, constraint violation, StatsModel exception, etc.), the catch block only writes a line to stdout/the cron log. next_run_at is already advanced to the next future occurrence, so that specific scheduled occurrence is gone forever with no record anywhere an admin would normally look — no audit_log entry, no Matrix alert, no failure table to review.
Fix: Add a Matrix/error-log alert specifically for this failure path (distinct from normal cron output), or persist failed-claim rows to a small table for manual review/replay, so a silently-skipped recurring ticket doesn't go unnoticed indefinitely.
**Severity:** Medium
`RecurringTicketModel::claimForRun()` intentionally advances `next_run_at` **before** `TicketModel::createTicket()` runs (`cron/create_recurring_tickets.php`) — a deliberate design choice (per an existing code comment) to prevent duplicate-ticket floods if creation fails partway and the cron retries.
**Impact of that tradeoff:** if `createTicket()` then fails (DB blip, constraint violation, StatsModel exception, etc.), the catch block only writes a line to stdout/the cron log. `next_run_at` is already advanced to the *next future* occurrence, so that specific scheduled occurrence is gone forever with no record anywhere an admin would normally look — no audit_log entry, no Matrix alert, no failure table to review.
**Fix:** Add a Matrix/error-log alert specifically for this failure path (distinct from normal cron output), or persist failed-claim rows to a small table for manual review/replay, so a silently-skipped recurring ticket doesn't go unnoticed indefinitely.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Severity: Medium
RecurringTicketModel::claimForRun()intentionally advancesnext_run_atbeforeTicketModel::createTicket()runs (cron/create_recurring_tickets.php) — a deliberate design choice (per an existing code comment) to prevent duplicate-ticket floods if creation fails partway and the cron retries.Impact of that tradeoff: if
createTicket()then fails (DB blip, constraint violation, StatsModel exception, etc.), the catch block only writes a line to stdout/the cron log.next_run_atis already advanced to the next future occurrence, so that specific scheduled occurrence is gone forever with no record anywhere an admin would normally look — no audit_log entry, no Matrix alert, no failure table to review.Fix: Add a Matrix/error-log alert specifically for this failure path (distinct from normal cron output), or persist failed-claim rows to a small table for manual review/replay, so a silently-skipped recurring ticket doesn't go unnoticed indefinitely.