Cache restore race condition? about composer-install

[mpdude]

I am sure this is the race condition as I initially described. Here is the log output of another run that worked:

PHP version is 7.2.34-21+ubuntu18.04.1+deb.sury.org+1
Operating system is linux
Cache primary key is linux-php-7.2.34-21+ubuntu18.04.1+deb.sury.org+1-locked-bac6c14ffff580a04a4fea1394e68aa862bb682755fbc9d2277682591500a408-
Cache restore keys are: linux-php-7.2.34-21+ubuntu18.04.1+deb.sury.org+1-locked-bac6c14ffff580a04a4fea1394e68aa862bb682755fbc9d2277682591500a408-, linux-php-7.2.34-21+ubuntu18.04.1+deb.sury.org+1-locked-
/usr/local/bin/composer install --no-interaction --no-progress --ansi
Installing dependencies from lock file (including require-dev)
Verifying lock file contents can be installed on current platform.
Received 49209747 of 49209747 (100.0%), 123.8 MBs/sec
Cache Size: ~47 MB (49209747 B)
/bin/tar --use-compress-program zstd -d -xf /home/runner/work/_temp/bba28022-b2f5-403f-9ceb-305964208faf/cache.tzst -P -C /home/runner/work/REPO/REPO
Cache restored successfully
Cache restored from key: linux-php-7.2.34-21+ubuntu18.04.1+deb.sury.org+1-locked-bac6c14ffff580a04a4fea1394e68aa862bb682755fbc9d2277682591500a408-
Package operations: 186 installs, 0 updates, 0 removals
  - Syncing webfactory/wfdynamic (3.1.0) into cache

You can see that /usr/local/bin/composer install --no-interaction --no-progress --ansi comes before Cache restored successfully, but this time, the cache was quick enough to be restored before Composer did any git clone operations.

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 require() in src/cache/factory.ts:

https://github.com/actions/cache/blob/0638051e9af2c23d10bb70fa9beffcad6cff9ce3/src/restore.ts#L69-L71

The run() call seems to trigger the actual cache restore code; but since that is async, it might take a while to complete. Does run() return a promise in this case, but that promise is never exported from the module?

If that is the case, what does this code here

composer-install/src/cache/factory.ts

Line 5 in 22e6d1c

return async () => await require('cache/dist/restore.js')

wait for?

[ramsey]

I have no experience with TypeScript or asynchronous programming in JavaScript.

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 await told it to wait, but that does seem in conflict with the async keyword. I'll check with some folks who know more about how JS works so I can get this to be more synchronous.

Thanks!

[mpdude]

Awesome. IMHO the run() in the restore.js file from actions/Core looks suspicious, since it seems to return a promise that we never get hold of.

That might be very difficult to fix, since it would require tweaking upstream code.

Looking forward to hearing from you 👨🏻‍💻

[clxmstaab]

we are also running in spurious errors which look like race-conditions to me. any progress on this front?

[ramsey]

This is fixed in v2, please upgrade using ramsey/composer-install@v2 or ramsey/[email protected]. Details are available on the release announcement and the README.

Thanks!