New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cache restore race condition? #152
Comments
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 I have no experience with TypeScript or asynchronous programming in JavaScript. That being said, here is the code from https://github.com/actions/cache that you The If that is the case, what does this code here composer-install/src/cache/factory.ts Line 5 in 22e6d1c
|
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 Thanks! |
Awesome. IMHO the That might be very difficult to fix, since it would require tweaking upstream code. Looking forward to hearing from you 👨🏻💻 |
we are also running in spurious errors which look like race-conditions to me. any progress on this front? |
This is fixed in v2, please upgrade using Thanks! |
Hey there 👋🏻 , thank you for this action! It makes my workflows (and thus) life much easier than having to deal with Composer and
actions/cache
myself.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
git
-cloned assource
, and I can't share all the details. But here is an excerpt from the raw logs with what I think is relevant.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
dist
files, but might be enough to makegit
stumble when it runs on a partly-restored repo?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: