Hi @Edgar,
During an Azure App Service deployment slot swap, the handling of in-flight API requests is designed to minimize disruption. Here are the key points regarding what happens to in-flight requests:
- If a client has sent a POST request and it is being processed when the swap occurs, that request will typically be completed by the original slot before the swap is finalized. The swap operation ensures that the target slot remains online while the source slot is prepared, which helps in completing ongoing requests.
- If a client's request is en route to the API and the swap occurs before the request arrives, the request will be delivered to the new slot. The routing rules are switched only after the source slot has completed its preparation and is ready to handle requests.
- The original slot is expected to complete all in-flight requests before the DNS routing changes. This is part of the design to ensure that users experience minimal disruption.
- There may be edge cases where a client might need to retry their request, especially if the swap operation encounters issues or if there are transient connection failures during the swap. Implementing client-side retry logic can help mitigate these situations.
Overall, Azure App Service aims to handle slot swaps gracefully to ensure that ongoing requests are processed without interruption.
Kindly refer to the below documentations for better understanding:
Set up staging environments in Azure App Service
Azure Functions deployment slots
If the answer is helpful, please click Accept Answer and kindly upvote it so that other people who faces similar issue may get benefitted from it.
Let me know if you have any further Queries.