Uh oh!
There was an error while loading. Please reload this page.
fix(v4/webpack): Deduplicate webpack deploys (#875) - #888
Conversation
Next.js Vercel deploys were creating duplicate deploy records (one per webpack compiler: client, server, edge) - Added a module-level guard (Set<string> keyed by release name) so newDeploy only fires once per release per process - Only guards newDeploy — all other release operations (create, finalize, setCommits) are idempotent and unaffected closes#873
Semver Impact of This PR🟢 Patch (bug fixes) 📋 Changelog PreviewThis is how your changes will appear in the changelog. Bug Fixes 🐛V4/Webpack
🤖 This preview updates automatically when you update the PR. |
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 3 potential issues.
Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.
| if (options.release.deploy) { | ||
| if (options.release.deploy && !_deployedReleases.has(options.release.name)) { | ||
| await cliInstance.releases.newDeploy(options.release.name, options.release.deploy); | ||
| _deployedReleases.add(options.release.name); |
There was a problem hiding this comment.
Race condition in deploy deduplication guard
High Severity
The check-then-act pattern (has() check, then await, then add()) creates a race condition when multiple webpack compilers run concurrently. Both compilers can pass the has() check before either executes add(), causing duplicate deploy records—the exact bug this PR aims to fix. The deduplication requires the release name to be added to _deployedReleases before the await, not after.
| // Module-level guard to prevent duplicate deploy records when multiple bundler plugin | ||
| // instances run in the same process (e.g. Next.js creates separate webpack compilers | ||
| // for client, server, and edge). Keyed by release name. | ||
| const _deployedReleases = new Set<string>(); |
There was a problem hiding this comment.
Unbounded Set growth in long-running processes
Low Severity
The _deployedReleases Set accumulates release names indefinitely without cleanup. Since release names typically use git SHAs or CI commit identifiers (changing with each build), the Set grows unbounded in long-running production build processes, causing a memory leak. While dev mode skips deploy creation, production CI/CD pipelines or continuous deployment systems could accumulate entries.
| ); | ||
| await managerA.createRelease(); | ||
| await managerB.createRelease(); |
There was a problem hiding this comment.
Tests don't verify concurrent execution scenario
Medium Severity
The test "should not create duplicate deploy records across separate plugin instances" uses sequential await calls instead of Promise.all, so it doesn't actually test concurrent execution. The race condition in the deduplication logic would only manifest when both createRelease() calls run truly concurrently, which this test doesn't verify.
Next.js Vercel deploys were creating duplicate deploy records (one per webpack compiler: client, server, edge)
closes#873
Backport of #875 to v4.