Skip to content

aws_s3: add sqs.idle_poll_period to back off idle SQS polling#4479

Open
peczenyj wants to merge 8 commits into
redpanda-data:mainfrom
peczenyj:aws-s3-sqs-idle-poll-period
Open

aws_s3: add sqs.idle_poll_period to back off idle SQS polling#4479
peczenyj wants to merge 8 commits into
redpanda-data:mainfrom
peczenyj:aws-s3-sqs-idle-poll-period

Conversation

@peczenyj

@peczenyj peczenyj commented Jun 2, 2026

Copy link
Copy Markdown
Contributor

Fixes #4478

What

Adds an optional sqs.idle_poll_period duration field to the aws_s3 input. When set (> 0) it replaces the fixed 500ms throttle applied after an empty SQS ReceiveMessage; the default 0s keeps current behaviour byte-for-byte.

Why

On an idle queue the input polls on a 500ms throttle (or ~every 20s with wait_time_seconds: 20). Deployments polling SQS from outside AWS (e.g. over a NAT gateway) want to back off further to cut request volume. The field stacks after wait_time_seconds long-polling and trades first-message latency for fewer requests.

Notes

  • Fully backward-compatible (default 0s).
  • Negative durations are rejected at config-parse time (there is no built-in duration lint rule).
  • The existing cancellation-safe wait in Pop makes a long idle period wake immediately on shutdown.
  • Unit tests cover config parsing (default, valid durations, negative guard), matching the existing config-parse test pattern for this input. The Pop back-off itself is not unit-tested: exercising it would require an SQS client interface seam that the input does not currently have (the pre-existing 500ms path is untested for the same reason).

peczenyj and others added 8 commits June 2, 2026 17:50
Adds an optional duration field plumbed through s3iSQSConfig and validated
(non-negative) at parse time. Behavioural wiring follows in the next commit.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
When set (>0) the configured duration replaces the fixed 500ms throttle
between empty SQS receives; the default 0s keeps the historical 500ms.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Extract the hardcoded 500ms empty-receive throttle into a named
defaultIdleThrottle constant, and compute the idle wait as
max(defaultIdleThrottle, idle_poll_period) so a configured value below
500ms is raised to the historical floor rather than polling SQS more
aggressively than the previous default. Documents the clamp in the field
description.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

aws_s3: configurable idle back-off for SQS polling (sqs.idle_poll_period)

1 participant