Evaluate if is it worth automatically extending the message visibility timeout (as an opt-in setting)

[mauroservienti]

Due to the way SQS works (message pickup + visibility timeout) there always is the possibility that, if message processing takes longer than the default (30") visibility timeout, it results in a duplicate message.

One option could be to keep track, in the transport/pipeline, of the visibility timeout of each message and automatically extend it (there is an AWS API for that) if needed.

[GurGaller]

We need this feature. SQS seems to provide a method to extend the visibility timeout.

The reason this is important is that we want to allow handlers to run for a long time (a few minutes), without causing SQS to retry the message (if the visibility timeout is too low) or take a long time to try again after a node fails (in case the visibility timeout is high).