fix(win): recover signing queue after transient errors

[davidebaraldo]

Summary

Fixes #9656.

When multiple files are signed in sequence, WinPackager.signIf() chains them through this.signingQueue using .then(). If any _sign(file) rejects, the queue enters a permanently rejected state and every subsequent .then() is skipped — so files queued after the failing one are silently never signed. With forceCodeSigning: false the build then completes shipping unsigned binaries instead of signing the rest.

Fix

Decouple the queue's internal state from the per-file result:

const promise = this.signingQueue.then(() => this._sign(file))
this.signingQueue = promise.catch(() => false)
return promise

• this.signingQueue is reset to a resolved promise after each operation (success or failure), so the next _sign always runs.
• The original promise is returned to the caller, so rejections still propagate — forceCodeSigning: true still throws, and the failing file's caller still sees its error.

Test plan

• Manual verification: transient rejection on one file no longer blocks signing of subsequent files
• Manual verification: forceCodeSigning: true still throws on signing failure
• Manual verification: normal signing flow (no errors) is unaffected
• Unit/integration test — open question, see PR comment

[changeset-bot]

🦋 Changeset detected

Latest commit: c8a4894

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 8 packages

Name	Type
app-builder-lib	Patch
dmg-builder	Patch
electron-builder-squirrel-windows	Patch
electron-builder	Patch
electron-forge-maker-appimage	Patch
electron-forge-maker-nsis-web	Patch
electron-forge-maker-nsis	Patch
electron-forge-maker-snap	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[mmaietta]

Has this been tested per your PR description? I noticed the suggested code in the Description doesn't match the actual code change. Can you please clarify which approach is intended?

[mmaietta]

Marking Request Changes until previous question is addressed

[davidebaraldo]

Hi @mmaietta — apologies for the confusion. The snippet in the description was from an earlier draft I revised before pushing; the committed code is the intended fix:

const promise = this.signingQueue.then(() => this._sign(file))
this.signingQueue = promise.catch(() => false)
return promise

I went with this shape rather than the (onFulfilled, onRejected) variant for two reasons:

1. Caller still observes the real outcome. promise is returned untouched, so await this.signIf(file) in signAndEditResources / signApp still throws on a real signing error and forceCodeSigning: true still aborts the build.
2. Only the internal queue is healed. Resetting this.signingQueue to promise.catch(() => false) means the next _sign starts from a resolved state, so a transient failure on one file no longer poisons the chain for every file queued after it. The onRejected form would have re-invoked _sign on the current file when the previous one failed, which conflates two unrelated files.

I've updated the PR description to match the committed code.

On testing: I haven't been able to commit a unit test yet. The queue lives inside WinPackager and signIf depends on signingManager.value / signWindows, so a meaningful test needs non-trivial mocking of the signing infrastructure — and a standalone test that just replicates the queue logic would drift from the real code. I verified the behavior manually against the original failure mode from #9656 (transient rejection on file A no longer skips files B, C, …; forceCodeSigning: true still throws).

Happy to invest in a proper integration test (e.g. mocking signWindows via jest module mock) if you'd like that gating the merge — just confirm the approach you'd prefer.