queue-reprocess

---

name: queue-reprocess description: Move failed messages from dead letter queues back to their main queue. Use when asked about "reprocess DLQ", "retry failed messages", "move DLQ messages", "republish dead letters". SKIP: diagnosing failures first (use queue-triage); checking counts (use queue-status). allowed-tools: Bash Read AskUserQuestion argument-hint: "[queue-name] [environment]" model: haiku disable-model-invocation: true

Step 0 — Load configuration

Check if /tmp/ops-suite-session/config.json exists:

• If yes, read it (pre-parsed by session-start hook).
• If no, read ${XDG_CONFIG_HOME:-$HOME/.config}/ops-suite/config.yaml (preferred) or the plugin's config.yaml (legacy), parse it, and write to /tmp/ops-suite-session/config.json for other skills to reuse. If neither exists, tell the user to run /ops-suite:configure (or copy config.example.yaml to ~/.config/ops-suite/config.yaml and fill in their values). Stop here.

Extract:

• message_broker — determines which adapter to load
• orchestrator — for connecting to the broker
• environments — connection details

Step 1 — Load adapter

Read the adapter file at adapters/{message_broker}.md (in this skill's directory). If the adapter does not exist, tell the user that the message broker {message_broker} is not yet supported and stop.

Step 2 — Determine target environment

If $ARGUMENTS contains an environment name, use it. Otherwise ask the user. Store the selected environment config as env.

Step 3 — Pre-flight: check triage

Check /tmp/ops-suite-session/last-triage.json:

If it exists and is less than 10 minutes old for the same DLQ:

• Skip triage, use cached results.
• Show: "Using triage from {minutes} ago: {summary}"

If it does not exist or is stale:

• Show: "This DLQ has not been triaged recently. Reprocessing without fixing the root cause will likely send messages back to the DLQ."
• Suggest: → Run /ops-suite:queue-triage {dlq_name} {env_name} first.
• Ask: "Continue anyway? (yes/no)"

Step 4 — Identify DLQ and target queue

If $ARGUMENTS contains a queue name, use it. Otherwise, list DLQs with messages and let the user pick:

DLQs with messages:
| DLQ Name                 | Messages | Target Queue         |
|--------------------------|----------|----------------------|
| {dlq_name}               | {count}  | {target_queue}       |

Determine the target (main) queue by:

1. Checking x-first-death-queue header from a sample message
2. Removing the DLQ suffix (e.g., .dlq, .dead-letter, .error)
3. Asking the user to confirm the target queue

Step 5 — Verify prerequisites

Use the adapter to check:

1. The DLQ exists and has messages
2. The target queue exists and has consumers
3. The required plugin/feature is available (e.g., shovel plugin for RabbitMQ)

If the target queue has 0 consumers, warn the user that messages will just pile up.

Step 6 — Confirm reprocessing

ALWAYS ask for explicit confirmation before moving messages.

Display:

Ready to reprocess:
  Source DLQ:    {dlq_name}
  Target queue:  {target_queue}
  Messages:      {count}
  Method:        {shovel/move/republish}

This will move {count} messages back to {target_queue}. Proceed? (yes/no)

Step 7 — Move messages

Use the adapter's preferred method (in order of preference):

1. Shovel — Create a temporary shovel to move messages (RabbitMQ)
2. Move — Use the Management API move feature
3. Republish clean — Fetch, strip death headers, republish to target exchange

Monitor progress

After starting the move:

1. Check the DLQ message count periodically
2. Check the target queue message count
3. Verify messages are being consumed (not just accumulating)

Step 8 — Verify completion

Once the DLQ is empty (or the expected count has been moved):

1. Confirm the DLQ message count is 0 (or reduced by expected amount)
2. Check the target queue for any new DLQ entries (messages failing again)
3. Check consumer logs for errors

Step 9 — Cleanup

1. Remove the temporary shovel (if created)
2. Kill any port-forward processes
3. Report the result

Step 10 — Purge (if needed)

If messages are not reprocessable (e.g., malformed payloads, already processed):

ALWAYS ask for explicit confirmation before purging.

Purge {count} messages from {dlq_name}? This is irreversible. (yes/no)

Output format

Reprocessing Summary:
  DLQ:           {dlq_name}
  Target:        {target_queue}
  Environment:   {env_name}
  Messages moved: {count}
  Method:        {method}
  Status:        {success/partial/failed}

Post-move check:
  DLQ remaining: {count}
  Target queue:  {count} messages, {consumers} consumers
  New DLQ entries: {count} (messages that failed again)

Cleanup:
  - Shovel removed: {yes/no/n/a}
  - Port-forward killed: {yes/no/n/a}