Post argues job queues hide their scheduling semantics

Sources: typesanitizer.com, HN discussion
Summary: An engineering post argues that job queues carry hidden semantic complexity that configuration files tend to obscure. When a scheduled job has not finished before its next trigger fires under a concurrency limit of one, an implementation must pick among four behaviors (parallel spawn, prefer new, wait, or prefer old), and each encodes a different assumption about the workload and fault model. The author works a repository-repacking example where scheduling a seven-hour weekend job every three hours fails badly under prefer-new semantics but behaves under prefer-old, and recommends modeling queue size, concurrency, and interval assumptions explicitly before deploying.
Why it matters: Queue overflow and duplicate or dropped jobs often trace to an unstated scheduling-semantics choice rather than a coding bug.