Staged Actions
Stage deletes, resends, edits, and redrives locally — then publish them as a reviewed batch.
Nothing in Tarmac mutates a queue directly. Queue-changing operations are staged into a local list, reviewed, and then published as a batch. This gives you an undo window (unstage anything before publishing), a review step (see exactly what will happen, grouped by action type), and honest per-action results.
The Four Actions
| Action | What publishing does | Removes the original? |
|---|---|---|
| Delete | DeleteMessage on the source queue | Yes |
| Resend | Sends a copy of the message (to the same queue by default, or a chosen target) | No |
| Edit & Resend | Sends a copy with an edited body and/or attributes | No |
| Redrive | Sends the message to its source queue, then deletes it from the DLQ | Yes (after successful send) |
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 — staging a new action for a message replaces its previous one. Staged messages get an action chip in the list, and each queue shows a staged count badge in the rail and on the Staged tab.
Edit & Resend
The editor opens with the message body in a JSON editor with linting and a Format JSON button, editable message attributes, and a destination queue selector. The body must be valid JSON to submit (and is re-validated at publish time). In bulk mode, the edited body and attributes apply to every selected message — useful for patching a batch of poison messages that all share the same defect.
Publishing
The Staged tab lists every pending action with its timestamp, message ID, action type, target queue, and the result of the last publish attempt. From there:
- Remove individual actions, or Clear Queue Actions to unstage everything.
- Publish Actions shows a pre-publish summary grouped by type, then executes each action sequentially with a progress bar, then reports totals: Success / Skipped / Failed, with a reason for every skip and failure.
Only successful actions leave the staging list. Skipped and failed actions stay staged with their status recorded, so you can fix the cause (usually: re-fetch to refresh receipt handles) and publish again.
Why Actions Get Skipped
Actions are re-validated at execution time. The common reasons:
- No valid live receipt handle — deletes and redrives require the message to have been received in this session, and act using that receive's receipt handle. Messages that are only in the cache from a previous session, or whose visibility window has lapsed, can't be safely deleted. Re-fetch the queue (with a longer visibility timeout) and re-stage.
- Message not found in local cache — the cached row was cleared after staging.
- Invalid edited body — an edit that no longer parses as JSON fails rather than sending garbage.
Publish while your visibility window is open
The reliable pattern for destructive batches: fetch with a visibility timeout that covers your whole session (e.g. 900s), stage, review, and publish in one sitting. Staging is cheap and local — but receipt handles are perishable, and SQS offers no way to delete a message you don't currently hold.
FIFO Queues
On resend and redrive, Tarmac forwards the original MessageGroupId and MessageDeduplicationId, so ordering groups are preserved. AWS-managed system attributes (sender, timestamps, receive counts, sequence numbers, trace headers) are stripped rather than forwarded — SQS assigns fresh ones.
FIFO deduplication can swallow resends
Because the original deduplication ID is preserved, resending a message to a FIFO queue within SQS's 5-minute deduplication window can be silently dropped as a duplicate. If a FIFO resend doesn't appear, wait out the window or use Edit & Resend (a changed body matters for content-based deduplication).
What Sending Preserves — and What It Doesn't
A resent message is a new message: new message ID, new timestamps, receive count reset to zero. Message attributes are forwarded with string typing — if your consumers depend on Number or Binary attribute data types, verify they tolerate string-typed values before replaying at scale. Tarmac does not set a delay on sent messages.