Unable to back out upgrade without wiping database

[mikaelfrykholm]

deserializer-error.log

[martin-lindstrom]

We need a lot more information here. What database are you referring to?

[mikaelfrykholm]

The procedure we tried was to upgrade our QA env from 1.1.2 to 1.2.1. The server managed to serialize and save new data to redis and when trying to back out the upgrade the server crashed with the error above. If the keys are volatile they might have expired by them selves. We did try waiting until they did. I did manage to get it running directly by wiping the database though.

[felix-hellman]

@mikaelfrykholm We can fix this for upcoming versions by not letting sessions to be read by other versions. This could perhaps not be sufficient with rolling updates however. I.e. if 50% of the nodes are running version A and 50% of the nodes are running version B and load is balanced between these freely they will get cache-misses on the sessions which will result in errors.

What do you think?

[felix-hellman]

I have been thinking about it a bit and I would strongly recommend a blue/green deployment for this application instead of a rolling update. Otherwise this would get more complicated than it needs to be e.g. handling multiple versions of the underlying relying party api (bankid api).

There are multiple ways to achieve something like this, but it is important to make sure that versions are not being mixed for a given user. I.e. if a user starts on version A it needs to remain on version A.

We could change the versioning scheme @martin-lindstrom but when the underlying api changes and adds more fields we would still need to throw exceptions to make sure versions are not being mixed during a session.