Introduction
Hi, I'm miruky.
I expected a one-minute queue visibility timeout to hide the body after the initial Amazon SQS Console receive. It did not. The follow-up Console poll retrieved the same body before that minute had elapsed, and the approximate receive count changed from one to two.
That result is not evidence that the saved queue setting failed. The current AWS guide for the Console receive workflow states that messages retrieved there remain available for re-retrieval. This hands-on reproduces that Console-specific behavior and separates it from the visibility-timeout contract used by application consumers.
The run uses one encrypted Standard queue, one fixed message, a 60 s queue visibility timeout, and a 20 s receive wait. It makes only a few request-priced SQS operations; current pricing and free-tier terms are linked below.
1. Create a queue with a short visibility timeout
The queue and every send and receive request in this run remain in us-east-1.
The header confirms United States (N. Virginia) while the SQS Console is in English. This fixes the Region for the queue and every timed receive.
Open Amazon SQS and search for miruky-gzmqkdcavoklnjoz. Confirm that no exact queue name exists before creation.
The exact filter for miruky-gzmqkdcavoklnjoz returns no queue. That empty result establishes the resource boundary before creation.
Choose Create queue, select Standard, and enter miruky-gzmqkdcavoklnjoz. Use a 60-second visibility timeout, a 20-second receive wait, zero delivery delay, and SQS-managed server-side encryption.
The top-of-form crop shows Standard and miruky-gzmqkdcavoklnjoz. The timed controls are proved on the saved configuration page next, while the default SQS-managed encryption choice is checked privately instead of stretching this image across the full creation form.
Open the queue after creation and verify both timed values. The visibility timeout is a queue-level default when a ReceiveMessage request does not supply a different timeout. A nonzero receive wait enables long polling, which queries all SQS servers and reduces false empty responses.
The saved configuration shows 1 with Minutes for visibility timeout, 20 with Seconds for receive wait, and 0 with Seconds for delivery delay. The one-minute value is the configured 60 seconds. This proves the queue configuration; it does not yet prove how the Console's manual polling workflow treats that setting.
2. Send one fixed message
Open Send and receive messages, enter visibility-proof as the body, and send it once. Leave the optional message group ID blank, keep delivery delay at zero, and do not add message attributes.
The body is visibility-proof, the optional message group ID is blank, delivery delay is zero, and no message attribute is added. This is the sole message added to the queue.
SQS should acknowledge the send. Do not publish the generated message ID, MD5 value, queue URL, queue ARN, or timestamp; none of them is required to demonstrate visibility behavior.
3. Poll the same message twice
Start polling, leave the returned item undeleted, and stop when its row appears. I inspected the fixed body and receive count through separate crops because the full details view contains generated identifiers and timestamps.
The body-only crop shows visibility-proof and excludes the surrounding message metadata. Keeping the rectangle on the Body tab prevents the message identifier and timestamps from entering the article image.
The separate count-only crop shows receive count 1. That value belongs to the selected row opened for the body crop above. A private SHA-256 hash of the Console-generated message ID ties the later receive back to this row without retaining the identifier. The current details view does not expose the receipt handle, and it is neither copied nor published.
Return to the queue list, enter the same receive workspace in the existing tab, and reload it so the previous result table is empty. Poll again immediately. In this run, the same body returned before the configured minute had elapsed.
The follow-up Console poll returns visibility-proof before the queue-level minute has elapsed. The private message-ID hash matches the initial receive, so this is not another message with the same text.
The later count-only crop shows receive count 2. A private monotonic log records that the follow-up receive completed inside the configured 60 s interval. No additional body was submitted, and both receives produced the same SHA-256 identifier hash.
4. Interpret the result as Console behavior
The current AWS Console receive-and-delete guide explains that messages retrieved with the SQS Console remain available for re-retrieval. The body and count sequence above matches that documented behavior.
The guide does not state which request parameter produces this Console behavior, so I will not infer an undocumented implementation detail from the UI. The narrower, verified conclusion is enough: a follow-up Console poll can retrieve the same message before the queue-level visibility timeout expires.
This makes the Console useful for manual inspection, but not for validating the in-flight lease of an application consumer. At the API layer, ReceiveMessage can carry its own VisibilityTimeout; when that parameter is omitted, the queue default applies. Test a worker through the exact SDK or API request path it will use in production.
Receiving still does not delete the message. Application consumers must delete successfully processed messages, and Standard queues still require idempotent handling because their delivery model is at least once. Each receive also generates a receipt handle; the DeleteMessage contract requires the most recent one.
Wrap-up
The saved queue page retained a one-minute visibility timeout, yet the SQS Console retrieved the same message twice before that minute elapsed and incremented its approximate receive count from 1 to 2.
AWS documents this as Console re-retrieval behavior. Treat the Console as a manual inspection surface, not as proof of an application's visibility-timeout semantics. Validate the real consumer at the SDK or API layer, delete only after successful processing, and keep Standard-queue processing idempotent.
Thanks for reading this far.
See you in the next one.
Disclosure: This article was written with AI assistance and independently verified against the linked primary sources and observed results.
Top comments (0)