v3.0.0: '.zip.sha512' uploads fail deterministically with ArrayBuffer chunk type error

[bpamiri]

Summary

Upgrading from softprops/action-gh-release@v2.6.2 to @v3.0.0 (both released 2026-04-12) causes every release-asset upload to fail deterministically when uploading .zip.sha512 files (and possibly other small text files). The error is:

##[error]The "chunk" argument must be of type string or an instance of
Buffer, TypedArray, or DataView. Received an instance of ArrayBuffer

This appears to be a regression introduced in v3.0.0 — v2.6.2 publishes the same files cleanly on the same runner.

Repro

Action invocation (wrapped in Wandalen/wretry.action@v3 for unrelated reasons):

- name: Create Snapshot Pre-Release
  uses: Wandalen/wretry.action@v3
  with:
    action: softprops/action-gh-release@v3
    attempt_limit: 3
    attempt_delay: 30000
    with: |
      tag_name: v4.0.0-SNAPSHOT+1657
      name: Wheels 4.0.0-SNAPSHOT+1657 (snapshot)
      prerelease: true
      overwrite_files: true
      files: |
        artifacts/wheels-base-template-*.zip
        artifacts/wheels-base-template-*.md5
        artifacts/wheels-base-template-*.sha512
        artifacts/wheels-core-*.zip
        artifacts/wheels-core-*.md5
        artifacts/wheels-core-*.sha512
        artifacts/wheels-cli-*.zip
        artifacts/wheels-cli-*.md5
        artifacts/wheels-cli-*.sha512
        artifacts/wheels-starter-app-*.zip
        artifacts/wheels-starter-app-*.md5
        artifacts/wheels-starter-app-*.sha512
        artifacts/wheels-module-*.tar.gz
        artifacts/wheels-module-*.tar.gz.md5
        artifacts/wheels-module-*.tar.gz.sha512
        artifacts/wheels-module-*.zip
        artifacts/wheels-module-*.zip.md5
        artifacts/wheels-module-*.zip.sha512

The action proceeds through the early files, then fails on wheels-module-*.zip.sha512 (a small ~129-byte SHA-512 hex digest file). The error is reproducible — every retry hits it at the same step:

2026-04-30T06:05:35.4865Z ⬆️ Uploading wheels-module-4.0.0-SNAPSHOT+1657.zip.sha512...
2026-04-30T06:05:35.5912Z ##[error]The "chunk" argument must be of type string or an instance of Buffer, TypedArray, or DataView. Received an instance of ArrayBuffer

(retry 30s later)
2026-04-30T06:06:21.5669Z ⬆️ Uploading wheels-module-4.0.0-SNAPSHOT+1657.zip.sha512...
2026-04-30T06:06:21.6434Z ##[error]The "chunk" argument must be of type string or an instance of Buffer, TypedArray, or DataView. Received an instance of ArrayBuffer

(retry 30s later)
2026-04-30T06:07:07.5682Z ⬆️ Uploading wheels-module-4.0.0-SNAPSHOT+1657.zip.sha512...
2026-04-30T06:07:07.6665Z ##[error]The "chunk" argument must be of type string or an instance of Buffer, TypedArray, or DataView. Received an instance of ArrayBuffer

2026-04-30T06:07:52.8403Z ##[error]Process returned exit code 1

Environment

• Runner: ubuntu-latest (GitHub-hosted)
• Node: 20 (whatever ubuntu-latest currently ships)
• Action versions tried:
  • softprops/action-gh-release@v3 (auto-resolves to v3.0.0): fails
  • softprops/action-gh-release@v2.6.2: works

Hypothesis

The error message points at Node's stream-write API rejecting an ArrayBuffer (it expects Buffer/string/TypedArray/DataView). Likely v3.0.0 changed how file content is read from disk — perhaps moving to fs.promises.readFile() returning Uint8Array.buffer (an ArrayBuffer) without a Buffer.from(...) wrap before piping to the upload stream. Node 20+ tightened type checking on stream writes; this would explain why v2.x works but v3 doesn't.

The fact that it fires consistently on the .zip.sha512 files is suggestive — those are tiny (128–130 byte) files that may exercise a different code path than larger binary uploads.

Workaround

Pin to v2.6.2:

uses: softprops/action-gh-release@v2.6.2

This is what we are doing in the meantime. We will re-pin to @v3 (or @v3.0.1) once a fix ships.

Related

Probably affects all v3.0.0 users uploading checksum/digest files alongside binaries. We are early adopters — v3.0.0 was published only 18 days ago.