Stage AWS SQS Message Changes

The message actions in this guide go into a local list first. You review that list, then publish it as a batch. That gives you an undo window, since you can unstage anything before publishing. It gives you a review step that shows exactly what will happen, grouped by action type. And it gives you a per-action result instead of one all-or-nothing outcome.

Message actions

Stage from the inspector header buttons for a single message, or multi-select in the list for bulk staging. Each message holds at most one staged action per queue, and staging a new action for a message replaces its previous one. The exception is an action that has already started executing — its send is confirmed, its delete is still pending, or its outcome is unknown. Tarmac refuses to replace or unstage it until you resolve it, because replacing it would forget that a copy may already be at the destination. Staged messages get a colored dot in the list — hover it to see which action is staged, and a staged delete also strikes through the message preview. Queues with staged work get an indicator in the queue list, and Staged shows the selected queue's count.

Send always opens a destination dialog. Known source queues sort first and are labeled, and the first compatible queue is selected by default. Check that destination before you stage. For Send, the delete-original toggle is off every time the dialog opens; reopening Edit & Send resumes the toggle along with the rest of your staged edit. It is available only while every selected message still has a live receipt. If it's disabled, fetch the messages again before you stage Send with delete. Edit & Send handles one message at a time.

Edit & Send

The editor opens with the message body in a JSON editor with linting, editable message attributes, and a destination queue selector. The body has to be valid JSON before you can stage the action. Once staged, review your edit any time from the inspector's Staged edit tab, and reopening Edit & Send for that message resumes your staged version instead of the original.

Publish a batch

The Staged workspace mode lists every pending action with its timestamp, message ID, action type, target queue, and the result of the last publish attempt, including the failure reason. From there you can remove individual actions that haven't started executing, or choose Clear Queue Actions to unstage everything.

Publish Actions shows a pre-publish summary grouped by type, runs each action in turn with a progress bar, then reports how many were published and how many failed. When only part of the batch publishes, the summary shows a warning rather than a success check. Select a nonzero Failed count to jump to the actions that need attention.

In Free, every control that would create or run a change is disabled with a Requires Tarmac Pro explanation. That covers the staging buttons in the inspector header and list toolbar, the Stage delete and Stage send row menu entries, Publish Actions, and Retry on an outcome-unknown action. Local cleanup stays available, so you can still review, unstage, and clear staged actions. Free keeps cached and live reads. Pro is required only for changes you make to the queue.

Successful actions leave the staged list. Failed actions stay staged. If a send succeeds but deleting the original fails, publishing again retries only the delete. If Tarmac closes mid-publish, the action is still in the drawer when you come back. Publish again and it picks up where it stopped. It never re-sends a message AWS already accepted, and it never deletes an original unless you chose Delete originals after successful send. If Tarmac cannot determine whether AWS accepted a send, the action becomes Outcome unknown. Choose Retry (may duplicate) to send again, or Keep original to discard the staged action. Retry asks you to acknowledge the possible duplicate first. On a FIFO queue the retry reuses the original deduplication ID, so SQS discards it if it arrives within five minutes of the first send.

When an action's delete cannot run — the message was consumed by a consumer, or you cleared the cache — publishing keeps failing with Message not found in local cache. Choose Keep the copy on a send, or Stop trying on a delete, to stop retrying it. Anything already sent stays at its destination, the message stays wherever it is, and the action leaves the staged list. Nothing is asked of AWS.

Why actions fail

Before publishing, Tarmac rechecks destructive actions and extends their visibility where it can. Common reasons an action fails:

• No live receipt handle. Deletes and send-with-delete need a current receipt whose visibility deadline is still safely ahead. Expired handles cannot be used.
• Message not found in the local cache. The cached copy was cleared after staging.
• Visibility extension failed. Tarmac cannot safely keep the message invisible for the batch.

FIFO queues

Tarmac keeps message-group order. Retries of the same staged send count as the same operation, so FIFO deduplication can suppress duplicates.

What a send preserves

A sent copy is a new message. New message ID, new timestamps, and receive count reset to zero. Tarmac preserves your message-attribute data types and values, including String, Number, custom data types, and Binary. It forwards the FIFO message group ID when there is one. It does not forward AWS-managed receive metadata.