Describe the feature
Add support for configurable per-failure visibility timeout control in the SQS message poller, enabling exponential backoff between processing retry attempts without requiring any application-level changes to message handlers.
Use Case
When processing messages, if an error occurs, it often doesn't make sense to retry the message immediately.
The visibility timeout of a message is usually set to the length of time + some buffer on how long it will take to process the message. So, if it's 30 seconds to process, then visibilty timeout will be 45 seconds. If we think of an error case though, where the error is caused by a downstream slow down, for example, a database having an issue, we may cycle through the number of retries allowed before going to the DLQ within a few minutes.
I would like it to be more programmatic on when the retry occurs based on information from the message. With this, I could set the retry for 1 minute from the first failure, but 3 hours after the 4th failure.
Proposed Solution
Two different options. Both options require surfacing ApproximateReceiveCount in SQSMetadata by populating it during deserialization in MessageMetadataHandler.CreateSQSMetadata().
Option 1 — Poller-level configuration
Add a Func<int, TimeSpan>? VisibilityTimeoutOnFailure delegate to SQSMessagePollerOptions. The framework calls ChangeMessageVisibility automatically in ReportMessageFailureAsync when a handler fails, using the returned delay. No handler changes required.
Option 2 — Handler-level return value
Extend MessageProcessStatus to allow returning a visibility timeout alongside a failure result, e.g. MessageProcessStatus.Failed(TimeSpan delay). The framework applies the delay when it processes the failed status. This gives per-message control at the cost of updating each handler.
Other Information
No response
Acknowledgements
AWS.Messaging (or related) package versions
AWS.Messaging
Targeted .NET Platform
.NET 8 +
Operating System and version
Linux Containers
Describe the feature
Add support for configurable per-failure visibility timeout control in the SQS message poller, enabling exponential backoff between processing retry attempts without requiring any application-level changes to message handlers.
Use Case
When processing messages, if an error occurs, it often doesn't make sense to retry the message immediately.
The visibility timeout of a message is usually set to the length of time + some buffer on how long it will take to process the message. So, if it's 30 seconds to process, then visibilty timeout will be 45 seconds. If we think of an error case though, where the error is caused by a downstream slow down, for example, a database having an issue, we may cycle through the number of retries allowed before going to the DLQ within a few minutes.
I would like it to be more programmatic on when the retry occurs based on information from the message. With this, I could set the retry for 1 minute from the first failure, but 3 hours after the 4th failure.
Proposed Solution
Two different options. Both options require surfacing
ApproximateReceiveCountinSQSMetadataby populating it during deserialization inMessageMetadataHandler.CreateSQSMetadata().Option 1 — Poller-level configuration
Add a
Func<int, TimeSpan>? VisibilityTimeoutOnFailuredelegate toSQSMessagePollerOptions. The framework callsChangeMessageVisibilityautomatically inReportMessageFailureAsyncwhen a handler fails, using the returned delay. No handler changes required.Option 2 — Handler-level return value
Extend
MessageProcessStatusto allow returning a visibility timeout alongside a failure result, e.g.MessageProcessStatus.Failed(TimeSpan delay). The framework applies the delay when it processes the failed status. This gives per-message control at the cost of updating each handler.Other Information
No response
Acknowledgements
AWS.Messaging (or related) package versions
AWS.Messaging
Targeted .NET Platform
.NET 8 +
Operating System and version
Linux Containers