After v4 upgrade: `webhook-type: webhook-trigger` step delivers duplicate messages, then hangs until the job timeout

[cmur2]

Description

Hi, we use this action in camunda/camunda (public repo) and noticed a strange behavior: After bumping the action from v3.0.5 → v4.0.0 (no other changes), a step using webhook-type: webhook-trigger began delivering the same message multiple times and then hanging with no further log output until the GitHub Actions job hit its timeout-minutes and was cancelled. Reverting to v3.0.5 resolves it.

What type of issue is this? (place an x in one of the [ ])

• bug
• enhancement (feature request)
• question
• documentation related
• example code related
• testing related
• discussion

Requirements (place an x in each of the [ ])

• I've read and understood the Contributing guidelines and have done my best effort to follow them.
• I've read and agree to the Code of Conduct.
• I've searched for any related issues and avoided creating a duplicate issue.

---

Bug Report

Filling out the following details about bugs will help us solve your issue sooner.

Reproducible in:

package version: v4.0.0

node version: 22

OS version(s): ubuntu:24.04

Steps to reproduce:

Unchanged across the up/downgrade except the action ref:

- name: Send notification
  uses: slackapi/slack-github-action@dcb1066f776dd043e64d0e8ba94ca15cc7e1875d # v4.0.0
  with:
    webhook: ${{ <secret> }}
    webhook-type: webhook-trigger
    payload: |
      blocks:
        - type: "section"
          text:
            type: "mrkdwn"
            text: "<a Block Kit mrkdwn string>"

Job has timeout-minutes: 5.

Expected result:

On v3.0.5: the step completes in ~1–2s and the message is posted once.

Actual result:

On v4.0.0:

• The same message is delivered to Slack multiple times (usually 5 copies per run).
• The step logs its resolved inputs and then produces no further output until the job is cancelled at the timeout — roughly 4+ minutes of silence.

We did not change retries; the logs show the default retries: 5 in both versions.

07:00:01Z  ##[group]Run slackapi/slack-github-action@<v4 sha>
07:00:01Z    webhook: ***
07:00:01Z    webhook-type: webhook-trigger
07:00:01Z    errors: false
07:00:01Z    retries: 5
07:00:01Z  ##[endgroup]
           (no output for ~4m20s)
07:04:21Z  ##[error]The operation was canceled.

(The job started at 06:59:17Z; the cancellation at 07:04:21Z matches timeout-minutes: 5.)

Attachments:

Example failed runs

• https://github.com/camunda/camunda/actions/runs/29898638740
• https://github.com/camunda/camunda/actions/runs/29808797086 (source of the timeline below)

[cmur2]

FYI: when creating new issues, the existing https://github.com/slackapi/slack-github-action/blob/main/.github/issue_template.md is ignored and I got presented with an empty form, probably because of the Github warning You are using an old version of issue templates. Please update to the new issue template workflow.

[WilliamBergamin]

Root cause looks like an upstream bug in the bundled @slack/webhook package (the v8 rewrite that shipped in v4.0.0), not in this action's own code. Filed upstream: slackapi/node-slack-sdk#2673.

Summary: v8's WebhookTrigger.send() reads a successful response with await response.json(). When the trigger endpoint returns a 2xx whose body isn't JSON-parseable, the parse throws after the workflow has already been triggered. That throw is treated as retryable, so p-retry re-POSTs — re-triggering the workflow each time. With the default retries: 5, that's ~5 duplicate deliveries and ~5 minutes of backoff before it gives up, matching the timeline here exactly. v3.0.5 bundled @slack/webhook@7.2.0 (axios), which returned the body without throwing on a non-JSON/empty body → a single delivery.

[cmur2]

Interim workarounds until an upstream fix ships:

Thanks for looking at it this quickly, downgrading to v3.0.5 is what we did!

[zimeg]

@cmur2 The example shared above has a "message" payload with text and blocks which might be intended to be an "incoming-webhook" technique instead of "webhook-trigger". Would changing this to the other technique fix these retries?

[cmur2]

@cmur2 The example shared above has a "message" payload with text and blocks which might be intended to be an "incoming-webhook" technique instead of "webhook-trigger". Would changing this to the other technique fix these retries?

I can try that but it has to wait a bit as I am unavailable next week.

[proski]

I can reproduce the issue with webhook-trigger and v4. The same message was posted 6 times from a single action invocation. After reverting to v3, the message was posted once. When using incoming-webhook with v4, the message was also posted once.

I migrated from a much older version 1.24.0 that didn't require webhook-type. The release notes gave me an impression was that webhook-trigger should be used in that case.

Recommended change: Set the webhook-type value to webhook-trigger, as shown in the example below.

I admit that I didn't read the whole release notes, I just searched for webhook-type. Perhaps there should be a specific text stating that webhook-trigger was missing, incoming-webhook should be used if no other changes are made to the setup.

Also, it would be nice if the action supported webhook-type: auto based on the webhook URL and/or warned if the URL looks wrong for the specified webhook-type.

I'm on GHE v3.18, github-runner 2.335.1.