Possible issue SessionRequest container timeout after upgrading to 4.1

We’ve found a potential issues with upgrades at customers. The sessionRequest container needs to perform some extensive data migration which is taking too long for some customers and hits a timeout. Currently we’ve only seen this in the appliance of Mark Plettenberg.

For 4.2 we’re going to apply a fix by increasing the timeout. We’re also investigating a better solution to this simultaneously but we’re not sure when that will be ready. 

If an upgrade fails/hangs at a customer you can verify if this is the root cause by checking the health status of the sessionRequests container in “Container Status” page. It’ll show that there’s 1 or more pending migrations. The same can be found in the container log when you check out portainer. If this is the case you can workaround this issue like this: 

1. Scale the session requests microservice to 0 (docker service scale VSI_sessionrequests=0)

2. Step into the sessionrequestDb container and execute the following script using psql one line at a time to keep track of the progress easier. 

ALTER TABLE "SessionRequests"."SessionRequests" ADD "TestType" integer NOT NULL DEFAULT 1;
UPDATE "SessionRequests"."SessionRequests" SET "TestType"='2'  WHERE "TestRunId" IS NOT NULL;
INSERT INTO "__EFMigrationsHistory" ("MigrationId", "ProductVersion") VALUES ('20200128123613_Version41TestType', '3.1.2'); 

3. Scale the session requests microservice to 0 (docker service scale VSI_sessionrequests=1)

When customers use the external DB this is the script to be executed.

ALTER TABLE [SessionRequests].[SessionRequests] ADD [TestType] int NOT NULL DEFAULT 1;
GO
UPDATE "SessionRequests"."SessionRequests"  SET "TestType"='2'  WHERE "TestRunId" IS NOT NULL;
GO
INSERT INTO [__EFMigrationsHistory] ([MigrationId], [ProductVersion]) VALUES (N'20200128123613_Version41TestType', N'3.1.2');