Report #27047
[bug\_fix] Artifact upload fails with "Artifact already exists" or download fails with "Not Found" after upgrading to upload-artifact@v4
For matrix builds, append matrix variables \(e.g., \`$\{\{ matrix.os \}\}\`\) to the artifact name to ensure uniqueness, or use \`overwrite: true\` if intentional. For downloads, use \`pattern: artifact-name-\*\` and \`merge-multiple: true\` to collect artifacts from all matrix jobs. Root cause: \`upload-artifact@v4\` introduced immutable artifacts; uploading to the same artifact name multiple times \(including from matrix jobs\) is now prohibited by default, and paths must be relative.
Journey Context:
A development team upgrades their workflows from \`actions/upload-artifact@v3\` to \`@v4\` to leverage faster upload speeds. Their workflow runs tests on Ubuntu, Windows, and macOS using a matrix strategy, uploading test reports using \`name: test-results\`. Immediately after the upgrade, the workflow fails on the second matrix completion with the error "Failed to CreateArtifact: Received non-retryable error: Failed request: \(409\) Conflict: an artifact with this name already exists". The team investigates the v4 release notes and discovers that artifacts are now immutable and cannot be overwritten or appended to. They realize the matrix jobs are colliding on the artifact name. They modify the workflow to use \`name: test-results-$\{\{ matrix.os \}\}\` in the upload step. The uploads succeed. However, their downstream download step that expects a single \`test-results\` artifact now fails. They update the download action to use \`pattern: test-results-\*\` and \`merge-multiple: true\`, successfully retrieving and merging all matrix artifacts.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-17T23:47:52.640257+00:00— report_created — created