422 error 'body is too long'

[roulettedares]

when running this example workflow step against an older repo with a lot of commits:

    - name: Release
      uses: softprops/action-gh-release@de2c0eb89ae2a093876385947365aca7b0e5f844 # v1
      with:
        tag_name: ${{ inputs.git-tag }}
        body_path: ../changelog.md
        token: ${{ env.GITHUB_TOKEN_ORG }}
        generate_release_notes: ${{ inputs.changelog == '' && true || false }}
        repository: ${{ github.repository }}

it fails with

Run softprops/action-gh-release@de2c0eb89ae2a093876385947365aca7b0e5f844
👩‍🏭 Creating new GitHub release for tag v0.1.0...
⚠️ GitHub release failed with status: 422
[{"resource":"Release","code":"custom","field":"body","message":"body is too long (maximum is 125000 characters)"}]
retrying... (2 retries remaining)
👩‍🏭 Creating new GitHub release for tag v0.1.0...
⚠️ GitHub release failed with status: 422
[{"resource":"Release","code":"custom","field":"body","message":"body is too long (maximum is 125000 characters)"}]
retrying... (1 retries remaining)
👩‍🏭 Creating new GitHub release for tag v0.1.0...
⚠️ GitHub release failed with status: 422
[{"resource":"Release","code":"custom","field":"body","message":"body is too long (maximum is 125000 characters)"}]
retrying... (0 retries remaining)
❌ Too many retries. Aborting...
Error: Too many retries.

I would expect the action to truncate the body to 125000 characters

[markoueis]

What can be done about this? Any workarrounds?

[ramsespostnl]

I've also experienced this issue. Are there any workarounds now in 2025?

edit: I didn't find a workaround, but I dit find the root cause of the 'too long release note', which was caused by Github inability to determine the previous version automatically for tags when there are multiple tags on a commit.

After I tried to create the release manually, I noticed that for my release it created releasenotes for the entire history instead of just compared to the previous release. After looking at how the 'previous' release tag is determined, I stumbled upon this thread: https://github.com/orgs/community/discussions/149281#discussioncomment-12071170
From this I learned:

just discovered that it looks like GitHub can only find the previous tag if that tag is alphabetically the first tag of any tag on its commit

In our deployment process we create deployment tags that are separate from the repository version, such that:

• repository main branch commit can have version: v2025-3-1
• and when it succesfully deploys to an environment it get's another commit: v2025-3-1-prd

With this knowledge combined I have now modified our release creation to use the standard version instead of the one with the deployment tag. Which works since now it is also the first tag alphabetically on that commit.