azure-servicebus-dlq

GitHub composite action for purging or redriving an Azure Service Bus dead-letter queue.

• PURGE — drains the target queue's DLQ using receive-and-delete mode.
• REDRIVE — copies each DLQ message back to the main queue. Preserves sessionId (when present), strips the DeadLetterReason / DeadLetterErrorDescription broker properties, and caps the run at the DLQ size snapshot taken at start so a message that re-dead-letters doesn't create a redrive loop.
• Slack notify — optional on-failure notification via a webhook URL (skipped when the input is empty).

name: Purge or Redrive DLQ
on:
  workflow_dispatch:
    inputs:
      action:
        type: choice
        required: true
        options: [PURGE, REDRIVE]
      queue:
        type: string
        required: true

permissions:
  id-token: write
  contents: read

jobs:
  run:
    runs-on: ubuntu-latest
    environment: azure # only if your federated credential is scoped to an environment
    steps:
      - uses: sourceallies/azure-servicebus-dlq@v1
        with:
          namespace: my-namespace.servicebus.windows.net
          queue: ${{ inputs.queue }}
          action: ${{ inputs.action }}
          azure-client-id: ${{ vars.AZURE_CLIENT_ID }}
          azure-tenant-id: ${{ vars.AZURE_TENANT_ID }}
          azure-subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }}
          slack-webhook-url: ${{ secrets.SLACK_WEBHOOK_URL }} # optional

• Caller job permissions — id-token: write and contents: read.
• Azure federated credential — configured to issue tokens for the caller workflow (scope it to the GitHub environment, ref, or workflow that invokes this action).
• Service principal role on the target namespace/queue — Azure Service Bus Data Owner is the simplest choice; it covers receive, send, and queue-runtime-properties reads. More granular role combinations work as long as all three are granted.

• Works on session-enabled and non-session queues without caller configuration. Purge uses receiveAndDelete (no session acceptance needed on the DLQ). Redrive copies sessionId only when the source message has one.
• Redrive takes one batch-of-1 receive per iteration to keep the receive-to-settle window narrow. If completeMessage fails after a successful send (lock lost / link detached), the log flags it and the DLQ copy will reappear on the next run — at-least-once semantics.
• All work happens in a single runner; no workflow-level parallelism.