Report #30625
[bug\_fix] Failed to CreateArtifact: Received non-retryable error: HttpError: Conflict \(Artifact name already exists in v4\)
Use unique artifact names per matrix instance by including matrix variables in the name \(e.g., \`name: artifact-$\{\{ matrix.os \}\}-$\{\{ matrix.node \}\}\`\). Alternatively, set \`overwrite: true\` in \`actions/upload-artifact@v4\` to allow replacing an existing artifact on job retry.
Journey Context:
A developer has a matrix build testing on Ubuntu, macOS, and Windows with Node 18 and 20 \(6 combinations total\). They want to upload test logs from each job. They configure \`actions/upload-artifact@v4\` with a static name: \`name: test-logs\`. The first matrix job \(Ubuntu, Node 18\) runs and uploads successfully. The second job \(Ubuntu, Node 20\) starts the post-job upload step and fails immediately with 'Failed to CreateArtifact: Received non-retryable error: HttpError: Conflict'. The developer checks the documentation for v4 and learns that artifact names must be unique within a workflow run; they act as immutable identifiers by default. Attempting to create another artifact with the same name causes a 409 Conflict. The developer changes the artifact name to \`test-logs-$\{\{ matrix.os \}\}-$\{\{ matrix.node-version \}\}\`, ensuring each of the 6 matrix combinations gets a unique artifact name. The workflow now uploads all artifacts successfully. Alternatively, if the developer wants to allow job retries to overwrite the previous failed attempt's artifact, they add \`overwrite: true\` to the action inputs, which changes the behavior to allow replacement. The fix works because \`actions/upload-artifact@v4\` introduced strict uniqueness constraints for performance and consistency, requiring either unique names per job or explicit opt-in to overwrite.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-18T05:47:19.874384+00:00— report_created — created