parallel download race condition errors out with: dest already exists
kneirinck opened this issue ยท 2 comments
Preflight Checklist
- I have read the contribution documentation for this project.
- I agree to follow the code of conduct that this project follows, as appropriate.
- I have searched the issue tracker for a bug that matches the one I want to file, without success.
Issue Details
- Electron Packager Version:
- 17.2.0
- Electron Version:
- v22.2.0
- Operating System:
- Arch Linux
- Last Known Working Electron Packager version::
- N/A
Expected Behavior
Parallel downloads of electron always succeed without issues.
Actual Behavior
Parallel downloads of electron sometimes fail with the error dest already exists
.
It basically boils down to what's described in #1421 and #1540
The moving of SHASUMS256.txt
for each download runs into a race condition.
To Reproduce
As it's a race condition that's happening when downloading data it's not that easy to reproduce.
One way I found is adjusting @electron/get
to not actually download the zipfile and only the checksum which makes it easier to download & move the checksum file at the same time.
Checksum fails afterwards for obvious reasons but at least it's quicker & easier to reproduce that way.
Additional Information
For now I've been able to fix this by not passing multiple platforms/archs at once and just running the packager multiple times.
The simple fix is to run downloads in sequence instead of in parallel but that slows down the downloading.
One other option would be with a similar fix as for the tests (see PR mentioned above) and downloading the checksum file explicitly before the other downloads run in parallel.
Another option would be @electron/get
fixing it internally to prevent such an issue when it's running in parallel.
๐ Thanks for opening your first issue here! If you have a question about using Electron Packager, read the support docs. If you're reporting a ๐ bug, please make sure you include steps to reproduce it. Development and issue triage is community-driven, so please be patient and we will get back to you as soon as we can.
To help make it easier for us to investigate your issue, please follow the contributing guidelines.
Thanks for the report @kneirinck! We've actually run into this somewhat frequently in CI on this very repo, which is annoying ๐ .