Keygen Publisher fails with VERSION_TAKEN for blockmap artifacts

[coderdenver9]

• Electron-Builder Version: 22.13.0
• Node Version: 16.6.1
• Electron Version: 14.0.0
• Electron Type (current, beta, nightly): current
• Target: mac

Hi! 👋 I'm really excited to see an official Keygen publisher. Zeke shared the news with me last week. As part of a new major release, my team is working on migrating our home-grown publisher/provider over to the official one, but we're encountering an issue when publishing on macOS.

When publishing a new release using the new Keygen publisher, the publish is failing with a VERSION_TAKEN error code. After digging around a bit, this seems to only happen for blockmap artifacts. I think this is because electron-builder is setting the release filetype to .blockmap for both the .zip and .dmg artifacts.

Checking out my Keygen request logs, I get visibility into the following API requests from electron-builder:

The first release request for the .dmg artifact is successful,

{
  "data": {
    "type": "release",
    "attributes": {
      "filename": "my-app-3.0.0.dmg.blockmap",
      "filetype": ".blockmap",
      "filesize": 88502,
      "version": "3.0.0",
      "platform": "mac",
      "channel": "stable"
    },
    "relationships": {
      "product": {
        "data": {
          "type": "product",
          "id": "15a7e0f1-c7da-4c05-984e-47ef1b664e70"
        }
      }
    }
  }
}

But a subsequent request for the .zip artifact fails,

{
  "data": {
    "type": "release",
    "attributes": {
      "filename": "my-app-3.0.0-mac.zip.blockmap",
      "filetype": ".blockmap",
      "filesize": 91526,
      "version": "3.0.0",
      "platform": "mac",
      "channel": "stable"
    },
    "relationships": {
      "product": {
        "data": {
          "type": "product",
          "id": "15a7e0f1-c7da-4c05-984e-47ef1b664e70"
        }
      }
    }
  }
}

It fails with the following API error response,

{
  "meta": {
    "id": "a71ea375-aa9c-408d-bc47-b1cce5428202"
  },
  "errors": [
    {
      "title": "Unprocessable resource",
      "detail": "already exists for 'mac' platform with 'blockmap' filetype on 'stable' channel",
      "source": {
        "pointer": "/data/attributes/version"
      },
      "code": "VERSION_TAKEN"
    }
  ]
}

As you can see, this makes Keygen reject the releases as duplicates, since the version property has to be unique for each product + filetype + filetype + channel combination. Meaning, .zip.blockmap and .dmg.blockmap are both being released as .blockmap, but they're conflicting with each other due to the "shared" filetype across multiple valid releases. Their docs mention using the "complete" filetype in cases where the artifact has multiple "valid" extensions.

To resolve this, I think electron-builder actually needs to set the filetype to .zip.blockmap and .dmg.blockmap, which is what our home-grown publisher currently does. This would also become an issue for .gz artifacts (for example .tar.gz), and any other multi-extension artifacts that are built by electron-builder.

If it helps, our home-grown publisher uses this package to get the "complete" extname: https://www.npmjs.com/package/path-complete-extname. I'm not sure if that'd work for everybody, but worth a mention. 🙂

[mmaietta]

Oh, bugger.

Thanks for the npm package link! If you're willing, please open a PR that swaps the current extname with the npm package you suggested. Otherwise, I should be able to get to this early this week.

[ezekg]

Good catch. I'm not super familiar with the blockmap stuff myself, so I guess this fell through the cracks when I was personally testing the publisher. That third-party lib you linked doesn't look like it'd handle artifacts such as Foo-1.0.0.exe.blockmap correctly (it counts the semver as file extensions) so not sure if it's a perfect solution outside of your specific pipeline. An artifact's extensions are hard to 'guess' from a string filename, as we can tell here, which is why the API explicitly requires the publisher to specify it. 🙂

@mmaietta I opened a draft PR that I think may work: #6234