perf(retrymq): cut idle Redis polling to one command per interval

[alexluong]

Implements #1014. Makes the rsmq receiveMessage script self-contained — it reads vt from the :Q hash and calls TIME itself, dropping the MULTI/HMGET/TIME/EXEC that preceded every receive (5 commands / 2 RTTs → 1 / 1). When nothing is due the script also returns the time until the zset's earliest score, so the monitor sleeps until the next message comes due instead of every 100ms. At the new default that's 129.6M → 86.4K commands per month, per monitor.

RETRY_POLL_BACKOFF_MS keeps its meaning — how long the monitor waits when idle — and is redefined as the maximum idle sleep, default 100 → 0, a sentinel meaning auto. Auto resolves to min(30s, shortest configured retry delay) (GetRetryPollBackoff), which makes added retry latency zero by construction for every config, including a custom retry_schedule with sub-30s entries. An explicit positive value is honored as-is — no cap — so a user can knowingly trade retry latency for idle cost (an earlier revision clamped explicit values to the shortest retry delay, which could silently lower a deliberately large value and raise the user's Redis cost). For any fixed value the new sleep is min(nextDue − now, X) ≤ the old flat X, so existing values only improve. Startup validation now rejects retry_schedule entries < 1, retry_interval_seconds < 1 (when no schedule is set), and negative retry_poll_backoff_ms.

Heads-up — the consecutive-error ladder no longer derives from pollBackoff: it now uses an internal 100ms base, so the ~1 minute of transient-infra tolerance documented at scheduler.go holds however the idle interval is configured. Previously raising the poll interval silently stretched (and lowering it shrank) that window.

Behavior changes (release notes)

• RETRY_POLL_BACKOFF_MS default 100 → 0 (auto). Auto sleeps until the next due message, at most min(30s, shortest configured retry delay). Retry timing is unchanged by construction; the idle Redis command rate drops ~600× (10 polls/s × 5 commands → ~1 command per interval).
• Explicit values are now a fixed maximum idle sleep, honored as-is. No clamping. A value larger than your shortest retry delay can add up to that much latency to retries scheduled while the monitor sleeps — that's now an explicit tradeoff you opt into, not a value we silently rewrite.
• Stricter config validation. Configs with retry_schedule entries < 1, retry_interval_seconds < 1 (when no schedule is set), or a negative retry_poll_backoff_ms now fail at startup instead of being silently accepted.
• Crash-redelivery edge. A message re-becoming visible after a crashed consumer (visibility timeout expiry) can take up to the idle sleep to be noticed, vs ~100ms before. Normal retry delivery is unaffected.

go test ./internal/rsmq/ ./internal/scheduler/ ./internal/config/   # Dragonfly
TESTCOMPAT=1 go test ./internal/rsmq/                               # + real Redis

🤖 Generated with Claude Code

[alexbouchardd]

See comment on issue regarding next message timestamp