Unable to publish assets to Github (ReleaseAsset asset_already_exists)

[mrfelton]

• Version: 20.38.4

• Target: mac/windows/linux

Since updating from 20.38.2 -> 20.38.4 electron-build has been unable to publish assets to a github release page. Downgrading to 20.38.2 resolves the issue.

It fails on publishing every asset from every os.

Here is an example:
https://travis-ci.org/LN-Zap/zap-desktop/jobs/469993385#L2805

2018-12-19T13:21:03.988Z electron-builder Response: 422 Unprocessable Entity, request options: {
  "hostname": "uploads.github.com",
  "path": "/repos/LN-Zap/zap-desktop/releases/13734557/assets?name=ZapDesktop-linux-i386-v0.3.0-beta.deb",
  "method": "POST",
  "headers": {
    "accept": "application/vnd.github.v3+json",
    "Content-Type": "application/octet-stream",
    "Content-Length": 52382742,
    "authorization": "<stripped sensitive data>",
    "User-Agent": "electron-builder",
    "Cache-Control": "no-cache"
  }
}
  • async task error error=
                       422 Unprocessable Entity
                       {
                         "message": "Validation Failed",
                         "request_id": "E166:5EBB:2E3AE0:33E8F0:5C1A45BF",
                         "documentation_url": "https://developer.github.com/v3",
                         "errors": [
                           {
                             "resource": "ReleaseAsset",
                             "code": "already_exists",
                             "field": "name"
                           }
                         ]
                       }
                       Headers: {
                         "cache-control": "no-cache",
                         "content-length": "211",
                         "content-security-policy": "default-src 'none'",
                         "content-type": "application/json; charset=utf-8",
                         "strict-transport-security": "max-age=31557600",
                         "x-accepted-oauth-scopes": "repo",
                         "x-content-type-options": "nosniff",
                         "x-frame-options": "deny",
                         "x-github-media-type": "github.v3; format=json",
                         "x-oauth-scopes": "public_repo",
                         "x-xss-protection": "1; mode=block",
                         "date": "Wed, 19 Dec 2018 13:21:04 GMT",
                         "connection": "close",
                         "x-github-request-id": "E166:5EBB:2E3AE0:33E8F0:5C1A45BF"
                       }
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! zap-desktop@0.3.0-beta package: `npm run build && npm run fetch-lnd && build "--publish" "onTagOrDraft" "--linux"`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the zap-desktop@0.3.0-beta package script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR!     /home/travis/.npm/_logs/2018-12-19T13_21_04_026Z-debug.log
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
Script failed with status 1
failed to deploy

If I delete the existing assets from the draft github release and try again then it works, but only the first time. Every subsequent attempt fails with the same error ^.

Here are some other similar issues where this was reported in the past:

• nsis-web: Github trying to release return "HttpError: 422 Unprocessable Entity" #2396
• Github publish asset_already_exists #2094
• Publishing app on appveyor fails ungracefully when asset has already been published #2337

[TrevorSayre]

I'm getting the same issue on 20.38.3, downgrading to 20.38.2 resolved this for me

20.38.3 error

Error #1 
HttpError: 422 Unprocessable Entity
{
  "message": "Validation Failed",
  "request_id": "...",
  "documentation_url": "https://developer.github.com/v3",
  "errors": [
    {
      "resource": "ReleaseAsset",
      "code": "already_exists",
      "field": "name"
    }
  ]
}

20.38.2 overwrite success

* overwrite published file file=<file> reason=already exists on GitHub

[SupremeTechnopriest]

@mrfelton @TrevorSayre This isn't a bug. The release you are trying to push already exists on github. You either have to bump your package.json version or delete the old release from github to overwrite the version.

[TrevorSayre]

@SupremeTechnopriest Not calling it a bug, personally, but it is a feature I need given how our release process creates a release that we want to overwrite with the files.

[mrfelton]

@SupremeTechnopriest in my case, the release only existed as a draft release. In the past this has always worked and I thought this was the standard process.

1. Create a draft release
2. Every build will upload new assets to the draft release, replacing those of prior builds
3. Publish the draft when you are ready to release.

Has this changed?

[SupremeTechnopriest]

You don't have to create the draft. It's creates automatically. =)

…

On Wed, Jan 2, 2019, 5:28 PM Tom Kirkpatrick ***@***.*** wrote: @SupremeTechnopriest <https://github.com/SupremeTechnopriest> in my case, the release only existed as a draft release. In the past this has always worked and I thought this was the standard process. 1. Create a draft release 2. Every build will upload new assets to the draft release, replacing those of prior builds 3. Publish the draft when you are ready to release. Has this changed? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3559 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACKCXvdfznzCD48SqsOfnRXhlOW9BNIGks5u_TJ3gaJpZM4ZaPe0> .

[SupremeTechnopriest]

That's probably why you are having issues.

[mrfelton]

Interesting. Is that a recent change?

[SupremeTechnopriest]

No idea, just started using electron. I know the docs are wrong.

…

On Wed, Jan 2, 2019, 5:40 PM Tom Kirkpatrick ***@***.*** wrote: Interesting. Is that a recent change? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3559 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACKCXsJlHWDmQFEUX7w0ajbTyppppuMqks5u_TVVgaJpZM4ZaPe0> .

[pgebheim]

There's definitely something buggy here -- the process of being able to update draft releases is how you can do -snapshot releases (as described in that section of the docs).

If we need to we could script deleting the old releases first in CI, but that's a regression and I don't see anything stating that was an intended change. Also, the fact that we get a 422 means that the code is now sending a different API request -- its not like electron-builder is just checking for the existence of a release and skipping it with good messaging.

[hacdias]

@SupremeTechnopriest in my case, the release only existed as a draft release. In the past this has always worked and I thought this was the standard process.

1. Create a draft release
2. Every build will upload new assets to the draft release, replacing those of prior builds
3. Publish the draft when you are ready to release.

Has this changed?

That's what we were expecting. But since we upgraded to the latest release, it broke. Any updates on this @develar?

[SupremeTechnopriest]

I guess something did change because you can't have the draft release created beforehand now. Electron builder creates it for you.

…

On Wed, Jan 30, 2019, 10:06 AM Henrique Dias ***@***.*** wrote: @SupremeTechnopriest <https://github.com/SupremeTechnopriest> in my case, the release only existed as a draft release. In the past this has always worked and I thought this was the standard process. 1. Create a draft release 2. Every build will upload new assets to the draft release, replacing those of prior builds 3. Publish the draft when you are ready to release. Has this changed? That's what we were expecting. But since we upgraded to the latest release, it broke. Any updates on this @pgebheim <https://github.com/pgebheim>? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3559 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACKCXtodUb9I3L9XSTW-zP4vQOkiHeEcks5vId8pgaJpZM4ZaPe0> .

[mrfelton]

Recommended GitHub Releases Workflow¶
Draft a new release. Set the “Tag version” to the value of version in your application package.json, and prefix it with v. “Release title” can be anything you want.

For example, if your application package.json version is 1.0, your draft’s “Tag version” would be v1.0.

Push some commits. Every CI build will update the artifacts attached to this draft.

Once you are done, publish the release. GitHub will tag the latest commit for you.
The benefit of this workflow is that it allows you to always have the latest artifacts, and the release can be published once it is ready.

Something is clearly wrong here.

You are supposed to create the draft yourself, and electron-builder is supposed to publish to the draft only if it exists. Electron Builder isn't supposed to be creating the draft releases for you when you are using the onTagOrDraft setting.

[hacdias]

Any updates on this? @develar

[polarathene]

@mrfelton not exactly a solution for everyone else here, but in regards to Travis CI and Github releases, why not use their releases(Github) deploy provider? You can build prior to deploy step this way, works well for me.

# Only build on code commits, not when tags are added(eg upon publishing a draft release)
if: tag IS blank

# Two build jobs, one on macOS, another on Linux with Docker to build Linux + Windows binaries
matrix:
  include:
    - name: "macOS"
      os: osx
      osx_image: xcode9.4
      language: node_js
      node_js: "10"
      env:
        - ELECTRON_CACHE=$HOME/.cache/electron
        - ELECTRON_BUILDER_CACHE=$HOME/.cache/electron-builder

    - name: "Windows + Linux"
      os: linux
      services: docker
      language: generic

# Clear out any cached files here
before_cache:
  - rm -rf $HOME/.cache/electron-builder/wine
  
# Keep files in these directories
cache:
  directories:
    - node_modules
    - $HOME/.cache/electron
    - $HOME/.cache/electron-builder

# Actual build command/script for the two jobs in the matrix above to use (could probably move these into each one?)
script:
  - |
    if [ "$TRAVIS_OS_NAME" == "linux" ]; then
      docker run --rm \
        -v ${PWD}:/project \
        -v ~/.cache/electron:/root/.cache/electron \
        -v ~/.cache/electron-builder:/root/.cache/electron-builder \
        electronuserland/builder:wine \
        /bin/bash -c "yarn --link-duplicates --pure-lockfile && yarn dist --linux --win"
    else
      yarn dist
    fi

# Workaround for bug in Travis deploy logic, `tag_name` isn't used for draft releases,
# Specify the tag to target in draft release instead for now via $TRAVIS_TAG
before_deploy:
  - export TRAVIS_TAG="preview"

# Deploy to Github Releases as draft release or update the existing one with the above `tag_name` value(any existing files will be overwritten)
deploy:
  provider: releases
  api_key: $OAUTH_TOKEN
  skip_cleanup: true
  draft: true
  overwrite: true
  file_glob: true
  file:
    - dist/*.exe
    - dist*.zip
    - dist/*.dmg
    - dist/*.snap
    - dist/*.AppImage

More details here.

The above .travis.yml will let you draft a release with the tag you want to use(you don't need to add a tag to a commit and can let the publish of the release assign a tag to a commit instead), with the example it works best as a placeholder tag and you adjust that to the actual tag you want to use when you manually publish a release. You could use a script instead to make that dynamic and say use the version from package.json.

This approach has a drawback in that as it deploys an update to the draft release each commit instead of when a commit is tagged(see alternate version in link provided), when the version is changed in the package.json, assuming your filees are appending that version to their filename, you'll need to discard the previous files that get added to the draft release when you bump the package.json version. The quoted workflow would supposedly run into the same issue though anyhow.

[rahulpnath]

Facing the same issue - Looks like it is unable to clean up an existing draft release and upload the latest packages. Does not have anything to do with creating a draft release/not doing it upfront, as this is the subsequent release after initial draft release with the same tag.

[thetroy]

in my case, the e instanceof HttpError check in gitHubPublisher.ts is failing, resulting in the error being rethrow instead of deleting the existing asset and retrying the upload.

instanceof fails because that e is an instance of the HttpError class defined here: node_modules/electron-publish/node_modules/builder-util-runtime/out/httpExecutor.js

but we are asking if it is an instance of the HttpError class defined here:
node_modules/builder-util/node_modules/builder-util-runtime/out

also here's my npm list builder-util-runtime builder-util output:

├─┬ electron-builder@20.39.0
│ ├─┬ app-builder-lib@20.39.0
│ │ ├── builder-util@9.7.0  deduped
│ │ ├── builder-util-runtime@8.2.0 
│ │ └─┬ electron-publish@20.39.0
│ │   ├── builder-util@9.7.0  deduped
│ │   └── builder-util-runtime@8.2.1 
│ ├─┬ builder-util@9.7.0 
│ │ └── builder-util-runtime@8.2.1 
│ ├── builder-util-runtime@8.2.0 
│ └─┬ dmg-builder@6.6.0
│   └── builder-util@9.7.0  deduped
└─┬ electron-updater@4.0.7
  └── builder-util-runtime@8.1.1 

from here, I'm not sure how to resolve:

• multiple versions of builder-util-runtime is not ideal. But assuming the paths i found and the dependency tree match, both HttpErrors are from a version 8.2.1
• I think githubPublisher should import HttpError along with httpExecutor (ie. from nodeHttpExecutor).

I'll post again when I have a workaround

[thetroy]

I opted to fix by exporting HttpError from nodeHttpExecutor, then importing from there in githubPublisher. This requires 2 files to be patched, which is not ideal. I could have instead replaced the instanceof tests with e.name === "HttpError". I opted for the import approach since it is my best guess as to how to fix this in the long term (i.e. in the typescript-based source).

I generate and apply patches using:
patch-package

if importing HttpError from nodeHttpExecutor seems like the proper way to resolve I can generate a PR.

[stale]

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

[gbacskai]

same issue came up upgrading from 22.11.7 to 22.13.1

[phanirithvij]

This still occurs with 22.13.1 @develar

[dfeverxx]

delete draft release from GitHub, and try to upload again, that fixes the issue for me

[mathiasvr]

This issue is specifically reintroduced in 22.13.0.

[lyswhut]

Same problem in v22.13.1
Last work version: 22.11.7

[TheExGenesis]

still happening in v22.14

[mmaietta]

I think this might be resolved via #6563
If so, it'll be in our next alpha release of v23.0.0-alpha.1

[martijnhartlief]

I'm having this exact issue in v23.3.3. (Replaced some sensitive data with ******)

• uploading       file=******.exe.blockmap provider=github
• uploading       file=******.exe provider=github
• overwrite published file  file=******.exe.blockmap reason=already exists on GitHub
HttpError: 422 Unprocessable Entity
"method: POST url: https://uploads.github.com/repos/******/******/releases/7[66]
(https://github.com/******/******/runs/8258036281?check_suite_focus=true#step:7:67)30150/assets?name=******.exe\n\n          
Data:\n          {\"message\":\"Validation Failed\",\"request_id\":\"0400:1175:8C5CF:B4ED6:631A5022\",\"documentation_url\":\"[https://docs.github.com/rest\](https://docs.github.com/rest/)",\"errors\":
[{\"resource\":\"ReleaseAsset\",\"code\":\"already_exists\",\"field\":\"name\"}]}\n          "