[HttpError]: Request body length does not match content-length header

[mrgmnn]

I am always receiving this error on first run and on rerunning this the error is gone in github actions. Any ideas?

[viceice]

It's happening here too: https://github.com/containerbase/internal-tools/actions/runs/7010134649/job/19070117802

[8:27:50 PM] [semantic-release] › ✔  Completed step "publish" of plugin "@semantic-release/npm"
[8:27:50 PM] [semantic-release] › ℹ  Start step "publish" of plugin "@semantic-release/github"
[8:28:06 PM] [semantic-release] › ✘  Failed step "publish" of plugin "@semantic-release/github"
[8:28:06 PM] [semantic-release] › ✘  An error occurred while running semantic-release: RequestError [HttpError]: Request body length does not match content-length header
    at /home/runner/work/internal-tools/internal-tools/node_modules/.pnpm/@octokit+request@8.1.6/node_modules/@octokit/request/dist-node/index.js:156:11
    at async requestWithGraphqlErrorHandling (/home/runner/work/internal-tools/internal-tools/node_modules/.pnpm/@octokit+plugin-retry@6.0.1_@octokit+core@5.0.2/node_modules/@octokit/plugin-retry/dist-node/index.js:71:20)
    at async Job.doExecute (/home/runner/work/internal-tools/internal-tools/node_modules/.pnpm/bottleneck@2.19.5/node_modules/bottleneck/light.js:405:18) {
  status: 500,
  request: {
    method: 'POST',
    url: 'https://api.github.com/repos/renovatebot/internal-tools/releases',
    headers: {
      accept: 'application/vnd.github.v3+json',
      'user-agent': '@semantic-release/github v9.2.3 octokit-core.js/5.0.2 Node.js/20.10.0 (linux; x64)',
      authorization: 'token [REDACTED]',
      'content-type': 'application/json; charset=utf-8'
    },
    body: '{"tag_name":"v3.0.18","target_commitish":"release","name":"v3.0.18","body":"## [3.0.18](https://github.com/renovatebot/internal-tools/compare/v3.0.17...v3.0.18) (2023-11-27)\\n\\n\\n### Build System\\n\\n* **deps:** update dependency typescript to v5.3.2 ([#427](https://github.com/renovatebot/internal-tools/issues/427)) ([468[80](https://github.com/containerbase/internal-tools/actions/runs/7010134649/job/19070117802#step:11:81)32](https://github.com/renovatebot/internal-tools/commit/46880321bbd8511cd24b921fb46921a8afab5148))\\n\\n","prerelease":false}',
    request: {
      agent: undefined,
      hook: [Function: bound bound register],
      retryCount: 3,
      retries: 3,
      retryAfter: 16
    }
  },
  pluginName: '@semantic-release/github'
}
RequestError [HttpError]: Request body length does not match content-length header
    at /home/runner/work/internal-tools/internal-tools/node_modules/.pnpm/@octokit+request@8.1.6/node_modules/@octokit/request/dist-node/index.js:156:11
    at async requestWithGraphqlErrorHandling (/home/runner/work/internal-tools/internal-tools/node_modules/.pnpm/@octokit+plugin-retry@6.0.1_@octokit+core@5.0.2/node_modules/@octokit/plugin-retry/dist-node/index.js:71:20)
    at async Job.doExecute (/home/runner/work/internal-tools/internal-tools/node_modules/.pnpm/bottleneck@2.19.5/node_modules/bottleneck/light.js:405:18) {
  status: 500,
  request: {
    method: 'POST',
    url: 'https://api.github.com/repos/renovatebot/internal-tools/releases',
    headers: {
      accept: 'application/vnd.github.v3+json',
      'user-agent': '@semantic-release/github v9.2.3 octokit-core.js/5.0.2 Node.js/20.10.0 (linux; x64)',
      authorization: 'token [REDACTED]',
      'content-type': 'application/json; charset=utf-8'
    },
    body: '{"tag_name":"v3.0.18","target_commitish":"release","name":"v3.0.18","body":"## [3.0.18](https://github.com/renovatebot/internal-tools/compare/v3.0.17...v3.0.18) (2023-11-27)\\n\\n\\n### Build System\\n\\n* **deps:** update dependency typescript to v5.3.2 ([#427](https://github.com/renovatebot/internal-tools/issues/427)) ([4688032](https://github.com/renovatebot/internal-tools/commit/46880321bbd[85](https://github.com/containerbase/internal-tools/actions/runs/7010134649/job/19070117802#step:11:86)11cd24b[92](https://github.com/containerbase/internal-tools/actions/runs/7010134649/job/19070117802#step:11:93)1fb46921a8afab5148))\\n\\n","prerelease":false}',
    request: {
      agent: undefined,
      hook: [Function: bound bound register],
      retryCount: 3,
      retries: 3,
      retryAfter: 16
    }
  },
  pluginName: '@semantic-release/github'
 ELIFECYCLE  Command failed with exit code 1.
}ERROR: "semantic-release" exited with 1.
 ELIFECYCLE  Command failed with exit code 1.
Error: Process completed with exit code 1.

[viceice]

It seems started to occure when we switched from node v18 to node v20 😕

[viceice]

🤔 It's working fine here: https://github.com/renovatebot/base-image/actions/runs/7071996205/job/19250354610

[mrgmnn]

Weirdly we did not change a thing. It started out of nowhere

[travi]

interesting. i have not seen this in my own projects yet. out of curiosity, are you depending on semantic-release in a way that it ends up in your lockfile? i'm wondering if this could be related to something stale in your dependency tree since we havent seen a ton of reports of this yet

[travi]

I don't see anything obvious to suggest it is related, but it does look like there was a GitHub incident during the time of the workflow referenced by @viceice. https://www.githubstatus.com/incidents/66vhjmd266r9

[travi]

an example of a successful release from using the default config, run with npx, without depending on semantic-release as a local dependency but letting npx install it as part of the release workflow.

this is feeling like something happened on the github side of things for a certain period of time and has since resolved. otherwise i would expect this to be happening consistently with lots of reports.

Are the failures youve seen clustered around a certain time period? Are you still seeing any of this sort of failure continuing?

[viceice]

I saw the issue constantly over multiple days. will check the pnpm lockfile and update deps to latest.

[viceice]

refreshed lockfile but still fails 😕

https://github.com/containerbase/internal-tools/actions/runs/7096328952/job/19314724111#step:8:1

[travi]

the only place where the content-length header should be getting set is when uploading assets as part of the github release. that is happening here: https://github.com/semantic-release/github/blob/30d75034246d4c76afdc2267cb56182c5964d793/lib/publish.js#L136C32-L136C32

i notice that the config for the project you linked to that is successfully releasing explicityly defines the assets list as an empty list whereas the config for the project that is failing does not define assets at all for the github plugin. it should be defaulting to an empty list, but i'm wondering if it is picking up the definition for the git plugin instead.

assuming you dont intend to attach assets to the github release, could you try setting assets to an empty list in that project too? that wouldnt fully explain why the behavior changed, but confirming that would narrow what we need to investigate.

[viceice]

doesn't work 😕

https://github.com/containerbase/internal-tools/actions/runs/7099052428/job/19322390468

i think it's failing here: https://github.com/semantic-release/github/blob/30d75034246d4c76afdc2267cb56182c5964d793/lib/publish.js#L81

will add some debug code via pnpm patch to see what's going on

[viceice]

I've now patched it to use node-fetch and it works as expected. So it really seems to be an issue with global node fetch (undici)

https://github.com/containerbase/internal-tools/actions/runs/7099585179/job/19323925406

Will now try a newer undici with this patch to verify

• https://github.com/nodejs/undici/pull/2305

[viceice]

ha, even undici v5.28.2 fails

• https://github.com/containerbase/internal-tools/actions/runs/7099744952/job/19324540392

[travi]

really appreciate the additional investigation, @viceice

if i'm understanding correctly, it sounds like you at least have a work around now with node-fetch, so that gives us an opportunity to try to figure this out properly without leaving you completely blocked, correct?

i still dont see clear conditions that make this happen since it still seems like most workflows using this plugin are succeeding. are the failures that you are seeing limited to just that repo? you referenced another repo, but only mentioned a success, so am i understanding correctly that you havent seen failures related to this there?

one detail that i notice in your output from failures is that the listed request headers dont even include a content-length header. maybe you already spotted that detail, but assuming that list of headers is correct, the error is even more strange. the api docs for creating a release dont seem to indicate that the content-length header is required, either.

[marcelkalveram]

We've also been experiencing this lately.

Error log:

[3:35:15 PM] [semantic-release] › ✘  An error occurred while running semantic-release: RequestError [HttpError]: Request body length does not match content-length header
    at /home/runner/work/[REDACTED]/node_modules/@octokit/request/dist-node/index.js:156:11
    at async requestWithGraphqlErrorHandling (/home/runner/work/[REDACTED]/node_modules/@octokit/plugin-retry/dist-node/index.js:71:20)
    at async Job.doExecute (/home/runner/work/[REDACTED]/node_modules/bottleneck/light.js:405:18) {
  status: 500,
  request: {
    method: 'POST',
    url: 'https://api.github.com/repos/[REDACTED]/releases',
    headers: {
      accept: 'application/vnd.github.v3+json',
      'user-agent': '@semantic-release/github v9.2.4 octokit-core.js/5.0.2 Node.js/21',
      authorization: 'token [REDACTED]',
      'content-type': 'application/json; charset=utf-8'
    },
    body: '{"tag_name":"v1.50.1","target_commitish":"main","name":"v1.50.1","body":"[REDACTED]","prerelease":false}',
    request: {
      agent: undefined,
      hook: [Function: bound bound register],
      retryCount: 3,
      retries: 3,
      retryAfter: 16
    }
  },
  pluginName: '@semantic-release/github'
}
RequestError [HttpError]: Request body length does not match content-length header
    at /home/runner/work/[REDACTED]/node_modules/@octokit/request/dist-node/index.js:156:11
    at async requestWithGraphqlErrorHandling (/home/runner/work/[REDACTED]/node_modules/@octokit/plugin-retry/dist-node/index.js:71:20)
    at async Job.doExecute (/home/runner/work/[REDACTED]/node_modules/bottleneck/light.js:405:18) {
  status: 500,
  request: {
    method: 'POST',
    url: 'https://api.github.com/repos/[REDACTED]/releases',
    headers: {
      accept: 'application/vnd.github.v3+json',
      'user-agent': '@semantic-release/github v9.2.4 octokit-core.js/5.0.2 Node.js/21',
      authorization: 'token [REDACTED]',
      'content-type': 'application/json; charset=utf-8'
    },
    body: '{"tag_name":"v1.50.1","target_commitish":"main","name":"v1.50.1","body":"[REDACTED]","prerelease":false}',
    request: {
      agent: undefined,
      hook: [Function: bound bound register],
      retryCount: 3,
      retries: 3,
      retryAfter: 16
    }
  },
  pluginName: '@semantic-release/github'
}
Error: Process completed with exit code 1.

Workflow file

jobs:
  semantic_versioning:
    name: Semantic versioning and changelog generation
    if: contains(github.event.head_commit.message, '[RELEASE]')
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repo
        uses: actions/checkout@v3.1.0

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 18.17.1

      - name: Get Library Versions For Binary Caching
        id: cache-settings
        run: |
          echo "dir=$(yarn cache dir)" >> $GITHUB_OUTPUT

      - name: Cache App Dependencies
        uses: actions/cache/restore@v3
        with:
          path: ${{ steps.cache-settings.outputs.dir }}
          key: ${{ runner.os }}-yarn-app-${{ hashFiles('yarn.lock') }}

      - name: Install Dependencies
        env:
          HUSKY_SKIP_INSTALL: 1 # Skip install of Husky
        run: yarn install --frozen-lockfile

      - name: Release
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: npx semantic-release

We didn't make any changes to our CI. The error seems to have shown up out of nowhere.

[viceice]

really appreciate the additional investigation, @viceice

if i'm understanding correctly, it sounds like you at least have a work around now with node-fetch, so that gives us an opportunity to try to figure this out properly without leaving you completely blocked, correct?

yes, pnpm patch is working for me until it's fixed upstream.

i still dont see clear conditions that make this happen since it still seems like most workflows using this plugin are succeeding. are the failures that you are seeing limited to just that repo? you referenced another repo, but only mentioned a success, so am i understanding correctly that you havent seen failures related to this there?

Yes, i only see this issue on that single repo since upgrading to node v20.

one detail that i notice in your output from failures is that the listed request headers dont even include a content-length header. maybe you already spotted that detail, but assuming that list of headers is correct, the error is even more strange. the api docs for creating a release dont seem to indicate that the content-length header is required, either.

🤷‍♂️ Yeah that's really strange. Maybe undici is adding it implicit and wrong?

[travi]

came across this comment in the undici repo highlighting that the content-length header is getting removed for a redirect. that got me to look at the error from the log again and noticed that the containerbase project is publishing to https://api.github.com/repos/renovatebot/internal-tools/releases instead of https://api.github.com/repos/containerbase/internal-tools/releases. i assume you moved the repo between orgs at some point?

semantic-release looks at the repository property in the package.json for repo details, so that being out of sync is causing the api request to go to the old location. normally, that isnt a big deal, because github redirects for transfers/renames. however, in this case it looks like it results in messing with the content-length header. i still dont understand why the header not being included would be considered a mismatch since i wouldnt expect all clients to include the header automatically, but that may just be me not thinking through things fully.

anyway, this seems likely enough to give updating the repository property to the new value a try worth a shot. i have a feeling that will make the problem go away for you.

[viceice]

🤦‍♂️ Thanks, yes we moved that repo and i'll fix that asap.

[viceice]

works now without patch 🎉 ❤️

• https://github.com/containerbase/internal-tools/actions/runs/7125317620/job/19401155668

[Manoj201]

is there any update regarding this issue Thanks

[travi]

is there any update regarding this issue

@Manoj201 have you checked that the repository property in your package.json matches your repository location? this appears to be related to redirects that result from that being out of sync after moving a repository.

I'm assuming that this issue is resolved if you get that detail into a good state, pending more information to prove otherwise. my plan was to close this issue out, so additional information would be helpful if you are seeing something else.

[Manoj201]

@travi Yeah, that was fixed now. everything working as expected. Thanks for the support

[unlight]

What is the solution? I'm still getting this error https://github.com/unlight/prisma-nestjs-graphql/actions/runs/7240117531/job/19722790687

[viceice]

What is the solution? I'm still getting this error https://github.com/unlight/prisma-nestjs-graphql/actions/runs/7240117531/job/19722790687

fix this url: https://github.com/unlight/prisma-nestjs-graphql/blob/c369e4eae095425f18e6a736e2bdf2bf7a7d5cd5/package.json#L9

[lukeocodes]

TL;DR - Updating the repo URL in the package.json file indeed resolved this error.

So the long and short for me was that this started after we renamed the repo, from "node-sdk" to "js-sdk" following isomorphic updates to the architecture. Months later the release pipeline broke, because we renamed the github repo (relying on the 301) after the major release, and did not-even patches since.

Worth noting that in earlier versions of semantic-release, this error was captured as "An unknown error occured" and a 500 status. It was only by updating semantic-release in our release process that I discovered the "Request body length does not match" error, which led me to this post.

Thanks for the diligent investigation!

[travi]

we've added feedback for this situation so that it is hopefully easier to spot going forward:

• https://github.com/semantic-release/github/issues/803
• https://github.com/semantic-release/github/releases/tag/v10.1.2

thanks @babblebey 🎉