SWA fails to call slow API

[jvannor]

I have a SWA built using Angular that is linked to a BYO Function App. The Function App links to a Serverless Azure SQL Database.

The system works fine until the SQL Database falls asleep. When this happens, the function encounters errors while it wakes SQL up. The function is configured with a long SQL Connection Timeout (180 seconds). It also uses EFCore with resilient connections (default configuration provides 6 retries). The combination of SQL Connection Timeout and EFCroe resiliency works well outside of the SWA environment - the function automatically retries, per configuration and ultimately succeeds in getting data from SQL after waking it up.

However, the same is not true when the function is linked to SWA and invoked from the client. The client appears to receive an HTTP 500 error after about 30 seconds. However, when viewing the log stream of the function app, it appears to continue running and completes its job - even after the client fails with the 500. It appears as if there is some sort of load balancer/proxy in between the SWA and BYO function that has set a timeout value of about 30 seconds. Is this true? Is there a way to adjust this timeout?

[jvannor]

I dug deeper into this problem and found that the issue really surrounds calling a slow API. There's a repro available here: https://github.com/jvannor/SlowApiTest

This repro has an Angular app with two buttons. The first button calls a "fast" API and works fine. The second button calls a "slow" API (C# function with a thread.sleep in it). The slow button always fails at/around the 45 second mark.

Run the slow API call under fiddler and you'll see it comes back like this:

HTTP/1.1 500 Internal Server Error Transfer-Encoding: chunked Date: Thu, 12 May 2022 14:55:22 GMT

14 Backend call failure 0

[trademark18]

Ah! I'm having the same issue! I'm using managed functions instead of BYO, and my function succeeds in about 45 seconds and shows a 200 response in Application Insights.

The client shows a 500 response, however, with "Backend call failure" inside it. There's not much to go on, but I suspect a similar issue to @jvannor based on observed behavior. I've tried to adjust timeouts anywhere I can, but there's still something messing it up.

Note that I also tried turning on the Enterprise-edge feature, and that exhibited the same behavior but with a 504 error message.

I did reproduce the behavior using Postman, so I know it's something on the Azure side and not an Angular thing.

[unowiz]

I am seeing this issue as well for an managed function that returns ~700KB data and takes ~50+ seconds (my function has to wait for data from an upstream api). A simple retry (reload page) seems to then complete the request magically in 4-5seconds.

[remirobichet]

I'm also experimenting the exact same issue as @trademark18 mentionned. Managed function and 45s to get a 500 error message with "Backend call failure".

Edit: I found some explanations on microsoft Q&A (https://docs.microsoft.com/en-us/answers/questions/544714/swa-azure-function-backend-returns-500-after-45-se.html) but no answer 😞

[tobiasdiez]

I also get the same error, 500 return code and "Backend call failure". However, in my case, this already happens after 10 sec.

As a first step towards a fix, could the "Backend call failure" please be logged to Application insights. It's so strange to see the function succeed with 200, don't see anything in the trace nor exception logs but still get a 500 error as the response.

[thomasgauvin]

Hi everyone, the timeout for any SWA or SWA API request is 45 seconds. It seems like these are long running operations that could be better achieved with async patterns https://learn.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-overview?tabs=csharp-inproc#async-http

[stefanello57]

Is there a way to increase this timeout or is there no other way around it than changing my deployed infrastructure (e.g. switching to durable functions)?

[forrestcoward]

Is 45 seconds really considered a long running request? It would be great to be able to configure the timeout of SWA Azure Function API like we normally would using Azure Functions, or even just get the Azure function default (5 minutes).

[marcelo-smartup]

Hey, how do we increase this?

[paul-wade]

This continues to cause problems. It's clear that SWA is for limited scenarios as this problem could be resolved but clearly MS is busy elsewhere.

[mjabl]

For me the 500 responses were caused by missing / outdated settings. In Azure Portal I navigated to Settings => Configuration and copied the relevant settings from my local.settings.json. Solved :)

[Izzmo]

This seems like a critical issue for adoption for any enterprise/well-used website.

[JeroenvdBurg]

Hi everyone, the timeout for any SWA or SWA API request is 45 seconds. It seems like these are long running operations that could be better achieved with async patterns https://learn.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-overview?tabs=csharp-inproc#async-http

@thomasgauvin If you are uploading a file stream from the frontend, durable functions are not going to help here. This really is a blocker to use BYO function with SWA. Why not make the timeout configurable?

Consumption plan functions have a default timeout of 5 min, premium functions even 30 minutes.

[FedyaNyet]

This needs to be fixed. We're trying to run a stream response which could take more than 45 seconds, and wouldn't fit an async paradigm.

[BenjaminIrwin]

This 100% needs to be fixed. Will likely have to switch away from Azure because of the problem.