.NET Core Error 502.3 while inserting into database

Question

I am inserting about 50k rows into a database using a PowerShell script and a .NET Core app (App 1 (PowerShell) is sending the data to App 2 (.NET Core), which id inserting the data).

I am using Entity Framework and I've implemented a mechanism in App 2 for faster inserting, something along the lines of this: Fastest Way of Inserting in Entity Framework

What happens is the inserting takes a little while, but it finishes fine with all the data being inserted correctly into the database. The query runs for about 4 minutes.

However, App 1 gets back a generic "HTTP Error 502.3 - Bad Gateway". This response gets returned even before all the data has been inserted into the database. So App 2 just sends back an error, but the db operations continue as if nothing happened.

So the problem is, the db inserts are working properly, but I have no way of knowing that in App 1, since all I get is a generic error every time.

I've tried increasing IIS timeouts, sessions timeouts in both apps, reading IIS logs and NET Core generated application logs. No success.

How do I make App 2 wait until the query is finished to get a proper response?

.NET Core version is 1.0.0-preview2-003121

Powershell request :

$post = Invoke-WebRequest -Uri ([string]$ApiUrl+$moduleApi) -Method Post -ContentType "application/json; charset=utf-8" -Body $json -Headers @{'ClientID' = "$clientID"; "Authorization"="Bearer $encryption"} -ErrorVariable errorMsg -UseBasicParsing -TimeoutSec 600

Answer 1

Increase requestTimeout to something that exceeds four minutes.

ASP.NET Core Module configuration reference

requestTimeout

Optional timespan attribute.

Specifies the duration for which the ASP.NET Core Module will wait for a response from the process listening on %ASPNETCORE_PORT%.

The default value is "00:02:00".

Answer 2

Set the requestTimeout to 0 - This means it will essentially wait indefinitely until the Database is done. The client just doesn't want to wait for the DB to finish, but the DB continues even after throwing the error.