409 Conflict on Existing File

[smashedr]

Not sure what caused this to crop up now, but uploading an existing file throws a 409 and fails the job.

https://github.com/cssnr/virustotal-action/actions/runs/18417322955

Most likely I was ignoring an error that is now not being ignored, which is a good thing.

TLDR: We need to catch the 409 status, and now that we have the SHA256, get the existing report:

https://www.virustotal.com/api/v3/files/{SHA256}

[smashedr]

I think we want to catch this here inside #process: https://github.com/cssnr/virustotal-action/blob/master/src/vt.js#L74

If the response data is the same, we can catch it inside #upload: https://github.com/cssnr/virustotal-action/blob/master/src/vt.js#L51

I will have to check the API. I also want to update axios to use a client for consistency and ease of use.

EDIT: Oddly I can't reproduce this bug locally... Which makes debugging/fixing a challenge...

[smashedr]

For anyone who runs into this, I believe this means you are hitting the API limit.

[ReenigneArcher]

Could retry logic be added to mitigate the issue? I'm occasionally getting random failures.

[smashedr]

Could retry logic be added to mitigate the issue? I'm occasionally getting random failures.

I believe this happens when you run more than 1 job back-to-back before the upload cooldown resets.

This is exactly what happened to me and I could not reproduce until I ran two jobs at once.

---

It sucks to have a job fail for a 409, even tho a manual re-run of the job, after the cooldown, should be successful.

I see this is still closed, are you suggesting we re-open this issue, and catch the error, and handle it gracefully? If so just press the button and I will eventually get around too it.

[ReenigneArcher]

I think there might be more to it than running jobs simultaneously, though that is where I see it most often.

I've also seen it when only one job is ran. I don't believe it's an rate limit issue because in my test release action I only upload a total of 2 artifacts (1 per test), and it couldn't exceed the 4 per minute rule.

I don't have permission to reopen the issue, but I think it could be solved with a retry loop that has an exponential backoff, maybe up to 5 retries?

[smashedr]

I think there might be more to it than running jobs simultaneously, though that is where I see it most often.

This will for sure cause it. The job has a rate limiter to prevent from ever hitting this in the first place. But that assumes it is the only job running, and their not running back to back.

I think adding a check for 409, and hold off for the necessary time, with maybe up to X number of retries (in the case of many simultaneous jobs) would be nice to have.

I will do some research on this, and look into getting this feature added.

I will also look into the re-opening issues thing, ive run into this on other repos, but not all.

[ReenigneArcher]

I will also look into the re-opening issues thing, ive run into this on other repos, but not all.

I believe only repo triagers/admins or the issue author can re-open issues. The author can only re-open it if they were the one that closed it.

[smashedr]

I tried many times to reproduce this error locally; however, can not get the rate limit to apply to my local IP, they let me upload 18 files back to back, multiple times.

Either way, reproducing the error won't change the data returned. Not only are they using 409 instead of 429, they do not provide any re-try information. Therefore, any attempt to retry would be blind and best effort.

So with that in mind, I am thinking maybe we can provide 2 options; retry and timeout. Where if we hit a 409, we could wait timeout seconds, and retry retry times before giving up.

@ReenigneArcher Let me know if this approach sounds right, and if you have any idea's for defaults. Maybe like 1-3 retries and 60-120 seconds.

---

response: {
  status: 409,
  statusText: 'Conflict',
  headers: Object [AxiosHeaders] {
    'content-type': 'application/json',
    'x-cloud-trace-context': '66f539e9eb565ec933f4bf92dd291c2e',
    date: 'Fri, 10 Oct 2025 20:13:43 GMT',
    server: 'Google Frontend',
    'content-length': '144',
    via: '1.1 google',
    'alt-svc': 'h3=":443"; ma=2592000,h3-29=":443"; ma=2592000'
  },
}

error: {
  code: 'ConflictError',
  message: 'Deadline exceeded retrieving concurrent execution result for c04cca5ebf46caf22face10bb1568bb0'
}

[ReenigneArcher]

I would probably go for an exponential backoff (double the delay between each attempt) instead of a fixed delay, but fixed delay is probably fine for this situation.

I think those 2 options are good with a default of 3 retries and 30 seconds between retries.

[smashedr]

I have an open PR with a possible solution: #32

I added 3 options to retry.

• retries - 3
• cooldown - 30
• multiplier - 2

This would result in a wait of 30 -> 60 -> 120.

I also introduced a new fail mode with 3 options:

• any - Fail the job if there are any failures.
• all - Fail the job only if all files fail.
• none - Don't fail for any failures.

Everything is up in the air.