Warn when Redis pending timeout is shorter than worker request timeout (+buffer)

[vinay0826]

Context

In OSS/self-hosted setups, operators sometimes increase
worker_request_timeout to accommodate slow endpoints.

The Redis visibility timeout (redis_pending_duration_secs) is configured
separately and remains global.

If worker_request_timeout is increased for slow deliveries but
redis_pending_duration_secs is not adjusted accordingly, Redis may
re-queue a task while the original worker is still processing it.

That can result in overlapping deliveries of the same message.

Change

This PR adds a startup guardrail:

If using a Redis-based queue and:

redis_pending_duration_secs < worker_request_timeout + 5s

a tracing::warn! is emitted during startup.

Why a Warning (Not a Hard Error)

The configuration is technically valid and may be intentional.
This change does not modify runtime behavior.

It simply highlights a potentially unsafe configuration
that could lead to duplicate in-flight deliveries when
handling slow endpoints.

Scope

• Applies only to Redis-based queue types
• No behavior change
• OSS/self-hosted safeguard only

[svix-jbrown]

good catch; one style nit (I believe our style is to prefer matches!() over batch blocks for booleans)

I wonder if we could detect the equivalent problem for SQS and RabbitMQ?

[vinay0826]

Rustfmt is keeping me humble today 😅.

Re: SQS/RabbitMQ — I took a look at the OSS backends. In this repo we only have Redis and RabbitMQ (no SQS here).

RabbitMQ doesn’t rely on visibility/pending timeouts — messages are only requeued on NACK or if the consumer/channel dies — so the “pending timeout < request timeout” mismatch doesn’t really apply there. That’s why I kept the guardrail Redis-only.

If SQS exists in Cloud/EE, then doing a similar check against the SQS visibility timeout vs worker_request_timeout would probably make sense on that side.