electron-builder: Error: Socket Hang up when electron-builder Release on github.

GitHub’s official actions/upload-artifact seems to resolve this issue by adding retries:

https://github.com/actions/upload-artifact/issues/116#issuecomment-754141048

Should be good now. Retries with exponential back-off have been added to all HTTP calls so any socket disconnects, timeouts, 503s or ECONNRESET errors should gracefully now retry and the artifact upload should go through (previously only a subset of HTTP calls during upload were retried). Recent updates should significantly improve reliability.

I’m still seeing this on an electron project I work on. When we run parallel windows and Mac builds on GH actions that publishes to GH releases, it seems to fail about 60% of the time with this error.

We’ve since switched to serialized builds and haven’t encountered the issue anymore, but it would be nice to have parallel builds again.

I’ve noticed something else: it doesn’t fail at the times my draft release is empty, i.e., when there is no need to overwrite files. Looking at all the examples you folks posted here, they all are trying to overwrite files. Is it possible that a change in GitHub API is the root cause?

You are absolutely right, it has only been randomly failing when I had a draft matching the same version. Now I have increased the version, it does no longer match the draft’s version so it now doesn’t randomly fail anymore

I have these observations from trying to debug this locally:

1. we never enter the if block where overwriteArtifact is called

https://github.com/electron-userland/electron-builder/blob/00e49e476ab103028d3e8d2543e34c041bc72878/packages/electron-publish/src/gitHubPublisher.ts#L200-L202

1. the description we get back from github is not json, but plain text, so the e.description.errors[0].code in the if statement is undefined since e.description has not been parsed into an object.
2. I do not believe this is the entirety of this problem, since I continue to also hit 502 bad gateway or other econnreset errors sometimes alongside, however this may be the root cause of the “can’t overwrite an already created draft release asset” problem

I’ll continue experimenting and debugging, and try and come up with a PR to fix at least this portion of these errors

the description we get back is like:

 description: 'method: POST url: https://uploads.github.com/repos/......./releases/......./assets?name=......exe\n' +
    '\n' +
    '          Data:\n' +
    '          {"message":"Validation Failed","request_id":".......","documentation_url":"https://docs.github.com/rest","errors":[{"resource":"ReleaseAsset","code":"already_exists","field":"name"}]}\n' +
    '          ',

same issue here, we are experiencing this error on-off for months 😦

I’ve noticed something else: it doesn’t fail at the times my draft release is empty, i.e., when there is no need to overwrite files. Looking at all the examples you folks posted here, they all are trying to overwrite files. Is it possible that a change in GitHub API is the root cause?

Well I tried like 10 times now and it seems always the same.

Can also confirm that this is still an issue, and yes, only occurs if the version tag already exists (i.e. it is overwriting a file).

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

I’m trying to debug the issue at version 22.11.7 using the strategy of patching the electron-publish package. I’m running electron-builder using GitHub Actions. This is the error thrown:

HttpError: 502 Bad Gateway
{
  "message": "Error creating policy",
  "request_id": "0403:2E2B:1F4F46:2A1335:60C4F970"
}
Headers: {
  "cache-control": "no-cache",
  "content-length": "83",
  "content-security-policy": "default-src 'none'",
  "content-type": "application/json; charset=utf-8",
  "strict-transport-security": "max-age=31557600",
  "x-content-type-options": "nosniff",
  "x-frame-options": "deny",
  "x-xss-protection": "1; mode=block",
  "date": "Sat, 12 Jun 2021 18:14:09 GMT",
  "x-github-request-id": "0403:2E2B:1F4F46:2A1335:60C4F970",
  "connection": "close"
}
    at createHttpError (D:\a\Rocket.Chat.Electron\Rocket.Chat.Electron\node_modules\builder-util-runtime\src\httpExecutor.ts:30:10)
    at IncomingMessage.<anonymous> (D:\a\Rocket.Chat.Electron\Rocket.Chat.Electron\node_modules\builder-util-runtime\src\httpExecutor.ts:179:18)
    at IncomingMessage.emit (events.js:388:22)
    at endReadableNT (internal/streams/readable.js:1336:12)
    at processTicksAndRejections (internal/process/task_queues.js:82:21) {
  statusCode: 502,
  description: {
    message: 'Error creating policy',
    request_id: '0403:2E2B:1F4F46:2A1335:60C4F970'
  },
  code: 'HTTP_ERROR_502'
}

I am wondering what the issue could be, if it’s not the timeout. Magically my builds now work again without any issues…

Have you tried that timeout change yet, by chance? Here’s a quick patch to apply that change for v22.10.5 in case anyone else interested. If it works, then I’m happy to incorporate the change

diff --git a/node_modules/electron-publish/out/gitHubPublisher.js b/node_modules/electron-publish/out/gitHubPublisher.js
index 75e5ca2..fa5ffa8 100644
--- a/node_modules/electron-publish/out/gitHubPublisher.js
+++ b/node_modules/electron-publish/out/gitHubPublisher.js
@@ -247,6 +247,7 @@ class GitHubPublisher extends _publisher().HttpPublisher {
       hostname: parsedUrl.hostname,
       path: parsedUrl.path,
       method: "POST",
+      timeout: 120 * 1000,
       headers: {
         accept: "application/vnd.github.v3+json",
         "Content-Type": _mime().default.getType(fileName) || "application/octet-stream",

Publishing is almost unusable. It is falling for me at a ratio of around one successful upload to five failed ones.

Hello 🖖🏻

I am also facing this issue since some weeks ago. I now always to re-run the Github Actions until it works.

https://github.com/Graviton-Code-Editor/Graviton-App/runs/1140459243?check_suite_focus=true

Notes:

• It fails randomly
• Only fails in Windows and Ubuntu

Question - how long does the upload take? This sort of error is something I’ve encountered elsewhere on long uploads