Consider rephrasing the handleMessageTimeout doc?

[Frederick888]

Background

AFAIU TimeoutError is not much different from regular processing errors, except for the fact that it emits a timeout_error event.

However handleMessageTimeout says:

By default, if handleMessage times out, the unprocessed message returns to the end of the queue.

To me, especially in the context of a FIFO queue, this sounds like that sqs-consumer will send a new message containing the same attributes and payload, then delete the original message.

I guess part of this is because 'the end' of the queue is unclear to me. According to https://en.wikipedia.org/wiki/Queue_(abstract_data_type)

By convention, the end of the sequence at which elements are added is called the back, tail, or rear of the queue, and the end at which elements are removed is called the head or front of the queue

Though in terms of a regular SQS queue, message aren't even always ordered in the first place (messages may occasionally arrive out of order. Despite this, standard queues make a best-effort attempt to maintain the order in which messages are sent). So perhaps it's better to simply avoid talking about front/back.

May I recommend changing this to:

By default, if handleMessage times out, the unprocessed message will not be acknowledged. The message may be visible again after the visibility timeout depending on the queue's retention period, redrive policy, etc.

Objectives

1. Clarify handleMessageTimeout