Getting deployment status and logs can cause race conditions

[ankitkumarr]

During kudulite function app build, if the client tries at any point of time to poll the deployment status and logs, we get locking issues which often cause the deployment to fail.

As a work-around, at the moment, the client is using /api/isdeploying endpoint to check if any deployments are ongoing. This can be unreliable if as it's not associated with a specific deployment id. Even with this setup, I still see a status.lock file in /home/site/locks with this error below --

"OperationName": "Getting deployment status",
  "AcquiredDateTime": "<my-timestamp>",
  "StackTrace": "   at System.Environment.get_StackTrace()\n   at Kudu.Core.Infrastructure.WindowsLockFile.WriteLockInfo(String operationName, Stream lockStream)
 in /tmp/KuduLite/Kudu.Core/Infrastructure/WindowsLockFile.cs:line 212
...

[Hazhzeng]

The root cause of this issue is due to a race condition when both DeploymentManager and the FileLogger try to access the same log file. Fixing the root issue should also mitigate this issue (also occurs in Kudu).

[ankitkumarr]

@Hanzhzeng, do you know when does that happen (the code block), and if you have a fix recommendation?
I know Sanchit was working on some locking improvements for Kudulite.

[Hazhzeng]

@Hanzhzeng, do you know when does that happen (the code block), and if you have a fix recommendation?
I know Sanchit was working on some locking improvements for Kudulite.

I heard that will be deployed by ANT 84, right?