[bug] Artifact overwrite doesn't always work

[dvd42]

What happened?

I run the following:

Run actions/upload-artifact@v4
  with:
    name: coverage-132-python_services_AI_PE
    path: coverage.xml
    overwrite: true
    retention-days: 15
    if-no-files-found: warn  
    compression-level: 6  

I get:

   With the provided path, there will be 1 file uploaded
Artifact 'coverage-132-python_services_AI_PE' (ID: 1554547722) deleted
Artifact name is valid!
Root directory input is valid!
Beginning upload of artifact content to blob storage
Uploaded bytes 2459
Finished uploading artifact content to blob storage!
SHA256 hash of uploaded artifact zip is ade371acd3b3694e3719d4f7e6a5e87d3d9f03ee3a9c4a7170c6f22ea588a488
Finalizing artifact upload
Artifact coverage-132-python_services_AI_PE.zip successfully finalized. Artifact ID 1554567367
Artifact coverage-132-python_services_AI_PE has been successfully uploaded! Final size is 2459 bytes. Artifact ID is 1554567367

I rerun it:

Run actions/upload-artifact@v4
with:
 name: coverage-132-python_services_AI_PE
 path: coverage.xml
 overwrite: true
 retention-days: 15
 if-no-files-found: warn
 compression-level: 6

With the provided path, there will be 1 file uploaded
Artifact name is valid!
Root directory input is valid!
Beginning upload of artifact content to blob storage
Uploaded bytes 2459
Finished uploading artifact content to blob storage!
SHA256 hash of uploaded artifact zip is 66e88e2c255466f590048ad87d1ad78adc4547825a47df05bbab9a95dc10b56e
Finalizing artifact upload
Artifact coverage-132-python_services_AI_PE.zip successfully finalized. Artifact ID 155586
Artifact coverage-132-python_services_AI_PE has been successfully uploaded! Final size is 2459 bytes. Artifact ID is 1555861812

Why on earth doesn't the file get overwritten in both cases? What am I doing wrong?

What did you expect to happen?

I expected the file to be overwritten in both cases

How can we reproduce it?

Yesterday it worked but I cannot get it to work again, so I cannot go back to a state where it works as expected

Anything else we need to know?

No response

What version of the action are you using?

Tried both 4 and 4.3.1

What are your runner environments?

linux

Are you on GitHub Enterprise Server? If so, what version?

No response

[pauldraper]

Same. overwrite: true doesn't prevent conflict from happening.

It seems to be non-deterministic; a re-run fixes it.

---

My money is on read-modify-write.

Will we ever improve?

[pauldraper]

My money is on read-modify-write

Will we ever improve?

upload-artifact/src/upload/upload-artifact.ts

Line 11 in 552bf37

async function deleteArtifactIfExists(artifactName: string): Promise<void> {

Though FWIW, I don't think this is sole source of the problem. I suspect@actions/artifact.

[VariantXYZ]

I seem to be hitting this issue while trying to setup dependency workflows (in my case, I don't actually want the job to be run multiple times, but it doesn't seem like there's a way to avoid it if I want to have clean dependency chains... anyway that's separate from this issue).

I'm guessing the issue has to do with some race condition on when the failing upload detects the upstream file for deletion as mentioned above...

Run actions/upload-artifact@v4
  with:
    name: zlib
    path: deploy
    retention-days: 1
    overwrite: true
    if-no-files-found: warn
    compression-level: 6
    include-hidden-files: false
/usr/bin/docker exec  7878ccf80f356a0485880cabb5e592859e334a2541d9cd2cccd8d98cd60e0dba sh -c "cat /etc/*release | grep ^ID"
With the provided path, there will be 5 files uploaded
Artifact 'zlib' (ID: 2524238627) deleted
Artifact name is valid!
Root directory input is valid!
Error: Failed to CreateArtifact: Received non-retryable error: Failed request: (409) Conflict: an artifact with this name already exists on the workflow run

However, within the same workflow that happens to be building zlib multiple times, I see it being uploaded and overwritten

Run actions/upload-artifact@v4
  with:
    name: zlib
    path: deploy
    retention-days: 1
    overwrite: true
    if-no-files-found: warn
    compression-level: 6
    include-hidden-files: false
/usr/bin/docker exec  1daa0646bd0883f142c275350ebfc586e090b1bb164f77e9f3470f27c909c1a4 sh -c "cat /etc/*release | grep ^ID"
With the provided path, there will be 5 files uploaded
Artifact name is valid!
Root directory input is valid!
Beginning upload of artifact content to blob storage
Uploaded bytes 93169
Finished uploading artifact content to blob storage!
SHA256 hash of uploaded artifact zip is 00a74a1a47e9fe4a25bab31731849ae428e6825d03bdc44d19995e52092a0ae4
Finalizing artifact upload
Artifact zlib.zip successfully finalized. Artifact ID 2524238649
Artifact zlib has been successfully uploaded! Final size is 93169 bytes. Artifact ID is 2524238649

Run actions/upload-artifact@v4
  with:
    name: zlib
    path: deploy
    retention-days: 1
    overwrite: true
    if-no-files-found: warn
    compression-level: 6
    include-hidden-files: false
/usr/bin/docker exec  1e47a5b439cf1d636a4ace56dc1cfcc017d7ff82ec9638119b136d5d6cd7bd80 sh -c "cat /etc/*release | grep ^ID"
With the provided path, there will be 5 files uploaded
Artifact 'zlib' (ID: 2524238582) deleted
Artifact name is valid!
Root directory input is valid!
Beginning upload of artifact content to blob storage
Uploaded bytes 93154
Finished uploading artifact content to blob storage!
SHA256 hash of uploaded artifact zip is 87e03cef015147a0b593a126b7164598d9c72fe3813c09d29c3bf7bffdaaef84
Finalizing artifact upload
Artifact zlib.zip successfully finalized. Artifact ID 2524238627
Artifact zlib has been successfully uploaded! Final size is 93154 bytes. Artifact ID is 2524238627

Seems pretty inconsistent.

[CanadaHonk]

This has made GH Actions unusable for a project for me: https://github.com/test262-fyi/test262.fyi. Pretty sure this is some kind of race condition because this action's overwrite trying to work around the upstream library changes and there is no nice solution other than making an alternative upload function there. Usually I could just downgrade to work around this but GH crashes CI when I do that because it is deprecated so there is just no solution for the moment other than rewriting on my end to avoid GH's bug.