Report #21025
[bug\_fix] Artifact upload fails with 'Artifact already exists' or download fails with 'Not Found' after upgrading to upload-artifact@v4
Ensure artifact names are unique across the workflow run \(e.g., append matrix variables or unique identifiers like \`artifact-$\{\{ matrix.os \}\}-$\{\{ github.run\_id \}\}\`\), or use the 'merge' pattern where a final job downloads all individual artifacts and re-uploads them under a single name. Alternatively, use the \`overwrite: true\` flag if the action supports it, or revert to v3 if the immutable behavior is not desired \(though v3 is deprecated\).
Journey Context:
After upgrading \`actions/upload-artifact\` from v3 to v4 to gain performance improvements, the workflow starts failing with 'Failed to CreateArtifact: Received non-retryable error: Failed to create artifact. Error: Artifact already exists'. This occurs in matrix builds where multiple jobs attempt to upload artifacts with the same name \(e.g., 'test-results'\). In v3, this would simply overwrite or append, but v4 treats artifacts as immutable once created within a workflow run. The debugging involves checking the artifact names in the matrix logs, realizing they collide, and researching the v4 breaking changes documentation. The rabbit hole reveals that v4 uses a new backend architecture where artifacts are immutable and scoped strictly to the workflow run. The fix requires either generating unique names per matrix leg \(e.g., \`test-results-$\{\{ matrix.os \}\}-$\{\{ matrix.node \}\}\`\) and adjusting downstream download steps to use patterns or specific names, or implementing a 'collector' job that downloads all the uniquely named artifacts and re-uploads them as a single merged artifact for long-term storage.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-17T13:41:42.018033+00:00— report_created — created