[Bug] Staging environment is not reliably closed when multiple PRs are closed at the same time

When multiple pull requests are closed at the same time, SWA frequently fails to close the current staging environment to free up that slot.

This became a much bigger problem when we started using dependabot on all of our projects and we are limited to only a single staging environment. If we have a handful of dependabot PR requests and we do a push to main which fixes them all, dependabot will go and close out all of the PRs that are now no longer applicable. However, if one of those PRs had successfully deployed to the staging environment on SWA, it commonly fails to be deleted. The only recourse is to go into the azure portal and manually delete that environment. It does not happen every single time, but commonly enough that it became quite bothersome.

We have now started using the suggestion in issue #122 to stop dependabot PRs from being deployed to a staging environment. at all and this has resolved the issue for us However, this does hint at a potentially larger problem which could occur anytime multiple PRs are closed at roughly the same time.

In the GHA logs, the PR which did not get deleted appears to have been first updated by dependabot (thus triggering a new build), then very shortly after closed (thus triggering the close event). In the GHA log, it looks like the deployment event fails after upload (it states: "Finished Upload.. Polling on deployment." then polls, then states that the deployment failed because the build was cancelled). Then, when the "close" job occurs, it declares that "The content server has rejected the request with: BadRequest Reason: No matching static site environment was found.". This prevents the staging environment from being deleted even though it clearly shows up in portal.azure and is still usable.

Is it possible that the post-deployment action which publishes the URL as a comment also sets up something which is then used later during tear-down? If the build is cancelled during the "polling on deployment" and then the PR is immediately closed, that seems to trigger the problem (relatively) reliably.