Problem
AWS SQS supports DelaySeconds at two levels:
- Queue level — every message on the queue is delayed
- Message level — only specific messages are delayed
kombu currently has no native way to set DelaySeconds at the message level.
Queue-level delay is too broad — different messages on the same queue have
different delivery requirements, so delay needs to be configurable per message.
When using kombu with Celery, the only workaround is countdown/eta — but
this is the wrong abstraction. countdown is a worker-side scheduling concept
where the worker waits before executing. DelaySeconds is a broker-side
concept where SQS holds the message before delivering it. These are
fundamentally different — using countdown forces unnecessary worker overhead
for something SQS handles natively with zero worker involvement.
Expected
Be able to set DelaySeconds on a specific message through kombu's SQS transport.
Suggestion
Expose delay_seconds as a parameter in Producer.publish() that flows
through to the SQS transport as DelaySeconds on the message.
Problem
AWS SQS supports
DelaySecondsat two levels:kombu currently has no native way to set
DelaySecondsat the message level.Queue-level delay is too broad — different messages on the same queue have
different delivery requirements, so delay needs to be configurable per message.
When using kombu with Celery, the only workaround is
countdown/eta— butthis is the wrong abstraction.
countdownis a worker-side scheduling conceptwhere the worker waits before executing.
DelaySecondsis a broker-sideconcept where SQS holds the message before delivering it. These are
fundamentally different — using
countdownforces unnecessary worker overheadfor something SQS handles natively with zero worker involvement.
Expected
Be able to set
DelaySecondson a specific message through kombu's SQS transport.Suggestion
Expose
delay_secondsas a parameter inProducer.publish()that flowsthrough to the SQS transport as
DelaySecondson the message.