[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:

github/lib/publish.js

Line 81 in 30d7503

} = await octokit.request("POST /repos/{owner}/{repo}/releases", release);

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

• fix: define conditions when content-length should be sent  nodejs/undici#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.