Queue Retry Policy Is Part of Data Integrity

Retry counts and backoff are not just performance settings when the job performs external side effects.

Reliable queues assume retries will happen and make handlers safe under repetition. Exponential backoff and jitter reduce synchronized pressure on failing dependencies. Automated publishing and operational jobs can fail because of temporary network errors, provider limits or local restarts. Retrying is necessary, but an unsafe retry policy can multiply side effects or overload a recovering dependency.

The queue controls how often the same business operation is re-entered. Without idempotency and backoff, retry becomes a source of corruption rather than resilience.

Publisher work is reconciled against durable delivery state before side effects are repeated, and operational jobs use bounded timeouts rather than uncontrolled loops. Classify errors as retryable or terminal, cap attempts, persist the last error and make manual replay use the same idempotent code path as automatic retry. The concrete hserver evidence is commit 999d414, so this note is tied to an actual production change rather than a hypothetical failure.