Skip to content

fix: avoid duplicate draft releases when publishing multiple dry runs#4326

Open
claude[bot] wants to merge 2 commits into
mainfrom
fix-github-publisher-duplicate-releases
Open

fix: avoid duplicate draft releases when publishing multiple dry runs#4326
claude[bot] wants to merge 2 commits into
mainfrom
fix-github-publisher-duplicate-releases

Conversation

@claude

@claude claude Bot commented Jul 21, 2026

Copy link
Copy Markdown
Contributor

Requested via Slack thread

  • I have read the contribution documentation for this project.
  • I agree to follow the code of conduct that this project follows, as appropriate.
  • The changes are appropriately documented (if applicable).
  • The changes have sufficient test coverage (if applicable).
  • The testsuite passes successfully on my local machine (if applicable).

Summarize your changes:

Before: Running electron-forge publish --from-dry-run with multiple saved dry runs (e.g. one per platform) against the GitHub publisher could create two or more draft releases for the same version, with the assets split between them. Each restored dry run triggers its own PublisherGithub.publish() call on the same publisher instance, and each call re-lists releases to find an existing one — but GitHub's "list releases" API is eventually consistent, so it can miss the draft release created just seconds earlier by the previous dry run, causing a second createRelease for the same tag.

After: Only one draft release is created per version. Subsequent publish() calls in the same process reuse the release they just found or created instead of re-querying the eventually consistent listing.

How: PublisherGithub now keeps an instance-level knownReleases map keyed by tag name. It is consulted before hitting the list/create APIs and populated after a release is found or created, so later calls for the same tag short-circuit to the known release. The two GetResponseDataTypeFromEndpointMethod type aliases were hoisted from the method body to module scope so the map can be typed. A regression spec (packages/publisher/github/spec/PublisherGithub.spec.ts) simulates the eventually consistent listing (always returning an empty list) and asserts that publishing two dry-run results for the same version creates exactly one release and uploads both assets to it.

Fixes #4325


Generated by Claude Code

When resuming multiple saved dry runs (publish --from-dry-run), the same
PublisherGithub instance is asked to publish once per dry run. Each call
listed the repository's releases to find the target release, but GitHub's
list releases API is eventually consistent, so a release created seconds
earlier by the previous call could be missing from the listing - causing
a second, duplicate draft release to be created for the same tag and the
platform assets to be split across the two drafts.

Remember the releases found or created during this process, keyed by tag
name, and consult that cache before hitting the list releases endpoint.

Fixes #4325
CI runners have no GITHUB_TOKEN in the environment, so the GitHub
client constructor threw before the mock could take effect. Pass an
explicit authToken through the publisher config and stub the env var
so the spec exercises the same code path everywhere.
@erickzhao
erickzhao marked this pull request as ready for review July 22, 2026 22:53
@erickzhao
erickzhao requested a review from a team as a code owner July 22, 2026 22:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

GitHub publisher creates duplicate drafts with multiple dry runs

2 participants