Report #17031
[bug\_fix] Artifact upload fails with "Conflict - Artifact already exists" or "Failed to CreateArtifact" in matrix builds
Use unique artifact names per matrix job by interpolating the matrix values into the artifact name \(e.g., \`name: my-artifact-$\{\{ matrix.os \}\}-$\{\{ matrix.node \}\}\`\). For v4 of upload-artifact, use the \`overwrite: true\` input if intentional replacement is desired. Root cause: Artifact names must be unique within a workflow run \(in v3 and earlier, subsequent uploads with the same name would fail; in v4, they are merged or overwrite based on settings, but concurrent matrix jobs racing to create the same name causes conflicts\).
Journey Context:
A developer sets up a matrix build to test on Ubuntu and Windows simultaneously. Both jobs produce a coverage report named \`coverage.xml\`. At the end of each job, they add \`actions/upload-artifact@v4\` with \`name: coverage-report\` and \`path: coverage.xml\`. When the workflow runs, one job succeeds in uploading, but the other fails with "Failed to CreateArtifact: Received non-retryable error: HttpError: Conflict - Artifact already exists" \(or in v4, it might fail with a different error about the artifact being finalized\). The developer realizes both jobs are trying to create an artifact with the identical name \`coverage-report\`, causing a collision. They modify the workflow to use \`name: coverage-report-$\{\{ matrix.os \}\}\`, creating separate artifacts \`coverage-report-ubuntu-latest\` and \`coverage-report-windows-latest\`. Alternatively, they could use the \`overwrite: true\` option if they actually want the last job to win, but usually, they want distinct artifacts. The root cause was the lack of namespacing for artifacts produced by parallel matrix jobs.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-17T04:18:21.270813+00:00— report_created — created