Skip to content

Conversation

itsparser
Copy link

Summary

  • Changed receive_filter to receive a single message instead of polling repeatedly
  • Returns NoData immediately if message doesn't match filter, delegating retry logic to caller
  • Simplifies implementation and provides more predictable behavior

Details

Previously, receive_filter would poll SQS repeatedly until a matching message was found or timeout was reached. This changes it to receive a single message and immediately return NoData if it doesn't match the filter.

The timeout parameter now represents the wait time for a message to arrive from SQS (long polling), rather than the total duration to keep polling for a matching message.

This provides:

  • More predictable behavior aligned with the timeout semantics
  • Simpler implementation without polling loop
  • Better control for callers who can implement their own retry logic if needed

Implement separate tracking for filter failures vs processing failures:
- Filter failures: Tracked via custom FilterFailCount message attribute
- Processing failures: Handled by SQS native redrive policy

When a message fails the filter max_filter_failures times, it's moved
to the configured DLQ. This prevents messages that never match filters
from cycling indefinitely while keeping filter failures separate from
actual processing failures (NACs).
Previously, receive_filter would poll SQS repeatedly until a matching
message was found or timeout was reached. This changes it to receive
a single message and immediately return NoData if it doesn't match
the filter, delegating retry logic to the caller.

This simplifies the implementation and provides more predictable
behavior aligned with the timeout parameter representing wait time
for message arrival rather than total polling duration.
@itsparser itsparser requested a review from a team as a code owner October 6, 2025 10:27
@svix-james
Copy link

Hi, I'm a bit confused by this PR. The PR title suggests you're changing existing behavior, but you're actually adding new functionality to receive/nack messages based on a filter? To be honest, this seems like an inefficient (and potentially expensive) use of SQS. I'm not sure it's something we'd want to support natively in the library.

Expose wrap_message method to allow external construction of Delivery
objects from SQS messages.
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.

2 participants