Build Script Race Condition Issue

When you are running the build-all.ps1 script in beta2 version, you might encounter occasional error in the CLI and/or Engine build window.

The error occured because the CLI and Engine window are trying to run dotnet publish command on a shared project. This lead to race condition where one process raised an error because a file is being used by another process.

The CLI and Engine are being run on two different windows. We’re using the powershell command Start-Process to open new windows. However, this create a separate thread for each window, thus creating the risk of the race condition. The correct way to handle this is to make the Start-Process syncronous by adding the -Wait argument. The problem is, the argument will hold the process until the window is closed. This is not fit into our use case, where we want to keep the window open so user can start using the CLI and Engine right in there.

The workaround we’ll be implementing in the beta3 version is to add a sleep thread using Start-Sleep command after opening the build CLI window, to reduce the risk of it being clashed with Engine build window. We are aware that this still have risk of race condition happened, if the CLI build process took longer than expected. However, we have yet to find a better solution. If you happened to encounter this error still, you can use the individual build script to re-build it. For example if you get an error in Engine window, please run the .\builds\build-engine.ps1 command manually in the Engine powershell window.

We’d love to hear your idea on how to mitigate this better.

1 Like

Good to know that we finally found the cause of the problem and a workaround.

For the real solution, perhaps we need to analyze what are the file that being used at the same time here. If we can control them (those files are the one that the script generated), perhaps we can put those files delicately for the Engine and the CLI instead of having both of them using the same files in single location?

Not a pretty solution, but I think the workaround will be quite useful for now. Let’s keep trying to find a permanent solution for this.

1 Like

@dzaki Thanks for your advise. The files being used are the obj folder files of Polyrific.Catapult.Shared.Dto project. The obj files are generated by the internal code of dotnet publish/dotnet build, and as far as I know, we cannot really control how it’s generated.

I hope this PR fixes the issue.


Nicely done @frandi :tada:
Thank you, sir.