This is to test the issues with teams.

From PR #24:

The current language reads:

The maximum visibility timeout is 12 hours from the time that Amazon SQS receives the message. Extending the visibility timeout does not reset the 12-hour maximum.

This is problematic, as "message" is used pervasively in the SQS documentation to refer specifically to the data plane entries stored in SQS queues, as differentiated from "request," which refers to a request intended to interact with the SQS control plane.

As written currently, it is easily misinterpreted to imply that there is a 12-hour maximum on visibility timeouts that begins when messages are enqueued (i.e. "from the time that Amazon SQS receives the message"), which would mean that the message retention periods for SQS FIFOs must correspondingly be set to less than 12 hours to ensure that messages are not received and processed out of order by concurrent consumers in a race.

Throughout the SQS Developer Guide the following sentence is repeated:

The default (minimum) visibility timeout for a message is 30 seconds. The maximum is 12 hours.

This makes it seem like the minimum visibility timeout is 30 seconds and the maximum value is 12 hours, however, the API (and console) state the minimum value is 0 seconds.

VisibilityTimeout - The visibility timeout for the queue, in seconds. Valid values: An integer from 0 to 43,200 (12 hours).

https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_CreateQueue.html

Have I missed a certain detail which makes it 30 seconds? Or do the docs need further clarification, for example:

The default visibility timeout for a message is 30 seconds. The minimum is 0 seconds. The maximum is 12 hours.

Happy to submit a PR either way to help others!

Marty

I don't understand this graphic for this explanation, it should be reviewed

Sorry first for that this problem might not under the scope of developer guide, but I could not find anywhere or suitable support category to report it.

In the site https://aws.amazon.com/sqs/pricing/

I find a meaningless place holder content under section
Learn how to get started
Quisque laoreet rhoncus rutrum. Sed nec lectus orci. Duis et nulla sit amet nisi finibus sagittis vitae vel arcu.

Hope any maintainer from AWS team could notify related teammates to fix it.

All the best.

Hello,

I am facing an issue with SQS standard queue. In SQS, as we know whenever a message is failed, it is stored in a dead letter queue (dlq) but the issue is when sqs is retrying to process the failed message, it is storing the same failed message again in the DLQ which causes the problem of duplicacy.

So, is there any way to remove duplicacy or a way such that if a message is retried it will not stored in the dead letter queue again if it is already there in the dead letter queue?

The documentation on SQS dead letter queues is mentioning a redrive policy. I think it should be mentioning a retry policy.

https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html

The policy document and description under "Example 5: Deny access if it isn't from a VPC endpoint" has a typo in the sample VPC id and condition.
https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-creating-custom-policies-access-policy-examples.html

In my system there is a main-queue and dead-letter-queue.

When any message failed in main-queue it goes to dead-letter-queue.

Reason of failing message in main-queue sometime random not critical i.e. message can be processed if reattempt from the main-queue.

There are 3 attempt to any failed message, meaning will send message to main-queue from dead-letter-queue only 3 times.

How can i track the message whether its 3rd attempt is exhausted and there is no need to send it back to main-queue for processing (will keep in dlq till it expire)?

@devlinbd2
RE: https://github.com/awsdocs/amazon-sqs-developer-guide/blame/main/doc_source/sqs-key-management.md#L58

What is meant by the IAM policy of the producer?

An SNS Topic is our producer but the only IAM policies attached to it are for delivery status logging and the access policy (This policy defines who can access your topic).

This note "Message deduplication applies to an entire queue, not to individual message groups." it's not always true considering the deduplication scope option: "Message Group" level.

Doc Link:
https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/using-messagededuplicationid-property.html

This should reflect in teams.

In here, it says that Don't use a dead-letter queue with a FIFO queue if you don't want to break the exact order of messages or operations.. As I understood that we use FIFO for preserving orders, but the documentation says the opposite. Am I missing something or the documentation is wrong?