We currently deploy a series of function apps in a matrix workflow. In other words, they are deployed in parallell.
At times we're facing a race condition, where two function deployments collide with eachother. The symptoms we see is that all deployments are successful, but certain functions are being provided with the code that belongs to a different function.
I've tracked this down to an issue with the blob URL that is applied as WEBSITE_RUN_FROM_PACKAGE. In the above example, two different deployments will point to the same blob, when they should reference different blobs
When two blobs are created within the same second, this means they will both be named exactly the same, for example Functionapp_2024314203942.zip. That's when we have a problem.
The blobs need to be named differently to ensure uniqueness. Not sure what the best solution would be -- suppose we could append getUTCMilliseconds() as well, but there would still be a risk of collision.
We currently deploy a series of function apps in a matrix workflow. In other words, they are deployed in parallell.
At times we're facing a race condition, where two function deployments collide with eachother. The symptoms we see is that all deployments are successful, but certain functions are being provided with the code that belongs to a different function.
I've tracked this down to an issue with the blob URL that is applied as WEBSITE_RUN_FROM_PACKAGE. In the above example, two different deployments will point to the same blob, when they should reference different blobs
The root cause seems to be due to the naming of the blobs, and the fact that they are time based with only second precision. https://github.com/Azure/functions-action/blob/1eed3b26fdf84515ada6204c0e15755039a26238/src/publishers/websiteRunFromPackageDeploy.ts#L51-L55
When two blobs are created within the same second, this means they will both be named exactly the same, for example
Functionapp_2024314203942.zip. That's when we have a problem.The blobs need to be named differently to ensure uniqueness. Not sure what the best solution would be -- suppose we could append
getUTCMilliseconds()as well, but there would still be a risk of collision.