You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When nacking SQS message I would expect it to the immediately returned back to the broker i.e. NACKing should set the VisibilityTimeout to 0. Current implementation does not seem to do anything.
Thank you for your feedback, the SQS connector is still in preview and if you are willing to contribute I can help to get in a configurable failure handler to change the message visibility of the nacked message.
You can do like the ack handler already existing on the SqsMessage, to add a failure handler. A first implementation for that failure handler would do nothing (current strategy) and a second implementation would do a call using the consumer client to send a request to set message visibility to 0 using the message id.
The connector channel can receive an attribute to choose between two strategies.
There are some other examples on other connectors. You can also check those.
When nacking SQS message I would expect it to the immediately returned back to the broker i.e. NACKing should set the VisibilityTimeout to 0. Current implementation does not seem to do anything.
https://github.com/smallrye/smallrye-reactive-messaging/blob/4.21.0/smallrye-reactive-messaging-aws-sqs/src/main/java/io/smallrye/reactive/messaging/aws/sqs/SqsMessage.java#L120
Also is there a way to manually extend the message's VisibilityTimeout in case it is about to expire when the processing takes longer than expected?
The text was updated successfully, but these errors were encountered: