Cache restore race condition? #152
Hey there 👋🏻 , thank you for this action! It makes my workflows (and thus) life much easier than having to deal with Composer and
However, I did a few test runs and noticed that I get failures every now and then, let's say in 1 out of 5 workflow runs. Those failures are transient and most of the time go away if I run the workflow again.
The bottom line error message is
Unfortunately, the Composer dependency in question is for a private repo that will be
What strikes me is the way how
happens just before the error, and how that is interleaved with the actual Composer run.
So, my suspicion is that some async operations go wrong here, so that the cache is restored while Composer is already running. Maybe that does not make much of a difference for
I should also add that I have some concurrent workflows that run this action here at about the same time. But to my knowledge, different workflows run in isolated environments. So I would rule out any kind of cross-workflow race conditions.
The text was updated successfully, but these errors were encountered:
I am sure this is the race condition as I initially described. Here is the log output of another run that worked:
You can see that
That being said, here is the code from https://github.com/actions/cache that you
If that is the case, what does this code here
My experience is also limited, but I think calling attention to the fact that there's absolutely asynchronous operations going on here points to a likely smoking gun.
In the code you pointed out, I thought the
Awesome. IMHO the
That might be very difficult to fix, since it would require tweaking upstream code.
Looking forward to hearing from you 👨🏻💻