Inconsistent errors in script—potential race conditions? #5172
Unanswered
AdreKiseque
asked this question in
Q&A
Replies: 1 comment
-
Related to: |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I've run into a few errors with WinGet in a script I'm working on that have been less than consistent in their manifestation, so I'm having a bit of trouble rooting them out. My best guess is they might be caused by some sort of race condition, but I really can't say for sure.
The first issue involves the installation of
Microsoft.PowerShell
, pwsh 7. On occasion, the installer fails with exit code1618
, saying "another installation is in progress". The commands are running in a loop, meaning they should be executed sequentially, so I'm not sure what this "other installation" could be. Unfortunately, the log was rather unhelpful, containing... nothing. It was just an empty file. This has happened rarely in testing but it's a pretty big issue considering later parts of the script rely on PowerShell 7 to function. My best guess at an explanation is WinGet is returning before previous installations in the loop are quite totally done, and PowerShell is bumping heads with the tail end of some previous operation cleaning up. But this would have to be a rather long cleanup considering WinGet has to actually download the pwsh installer before launching it, which should provide ample time for any remaining processes to wrap up.My second issue is a bit more straightforward. Running a simple sequence of
but got the absolutely bizarre error of
![image](https://private-user-images.githubusercontent.com/160550426/408704764-71a70308-5db1-4dd2-990a-9edc8ec6f208.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MzkzOTU2OTYsIm5iZiI6MTczOTM5NTM5NiwicGF0aCI6Ii8xNjA1NTA0MjYvNDA4NzA0NzY0LTcxYTcwMzA4LTVkYjEtNGRkMi05OTBhLTllZGM4ZWM2ZjIwOC5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjUwMjEyJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI1MDIxMlQyMTIzMTZaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1lZGM1NWFjNGJjZmI4Zjc3OTZhMTU3YTE0Nzg0ODQ2NzU4MGFhMzA5MDVlZWU5ZDhiYWMxMzBhNjgwNjg3ODE4JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.mYMHvf22uJXGrTyNqrJQAfoLlKFtYhTALEteIrLfYzk)
Unrecognized command: 'C:\Users\User\AppData\Local\Microsoft\WindowsApps\winget.exe'
on the second command, followed by the standardhelp
output. My best guess is, similar to the last problem, WinGet might be finishing up the last command and somehow rendering itself unavailable to be called when the next command runs. But the fact it gets the App Execution Alias path from just "winget" but says it "doesn't recognize it", while also generating WinGet output is just... I don't know.Can anyone make sense of any of this?
Addendum: Ok, now I'm really confused. In another test run, I got this
![image](https://private-user-images.githubusercontent.com/160550426/408814238-32e5faa7-5dac-460f-b5b1-24d50f5a14b5.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MzkzOTU2OTYsIm5iZiI6MTczOTM5NTM5NiwicGF0aCI6Ii8xNjA1NTA0MjYvNDA4ODE0MjM4LTMyZTVmYWE3LTVkYWMtNDYwZi1iNWIxLTI0ZDUwZjVhMTRiNS5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjUwMjEyJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI1MDIxMlQyMTIzMTZaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0wMGMyOTFiNGNhMTQ3ZDljYTM2MzhkZmQzZTgxMmQ5NTAwNDFiMmY2ZGIxNzkzNjRlOGJjNTU2M2Y2YjY2YTgxJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.vCRG6ckl_D9G-Jo42AHnTHA40r0JiRE3NF9vaUJKOmE)
"winget not recognized error" but just in the install loop. What the hell? How does this even happen?
Beta Was this translation helpful? Give feedback.
All reactions