That’s not an answer because type checking only protects against that class of errors. But you can have a logic bug in your upgrade code `if (old state) { buggy implementation of old compat } else { implementation for new state }` (or `convert(old state) -> new state` if the conversion is external). If you transparently just run the old code instead, then you’re not actually transferring state seamlessly and you run into the choice of “run N versions of code vs terminate sessions” when you have long running sessions. In any case, I think you start to run into real constraints and it’s not clear to me how Erlang solves these with it’s “2 simultaneous versions of the code only”.
> I think you start to run into real constraints and it’s not clear to me how Erlang solves these with it’s “2 simultaneous versions of the code only”.
There's different ways to handle it, but the 'easy' way is to write your new version that updates the old state to new state on first touch, and make sure either you have a no-op message you can send so the state gets updates or you have some periodic thing that means every state will be updated in X time.
There's also a way to have a 'try_update' that fails without changing anything if there are two versions active already. (Or you can just YOLO and anything with the old old version in the stack gets killed).
I'm not sure if there's better tooling for it now, but there wasn't anything to help you test transitions when I was doing it. For automated tests, you'd need to build a state with the old version, load the new version, run a test, etc. It's the same hole in testing if you do mixed version frontends against a shared database, or mixed version frontend vs backend; it's just more apparent because it's on a single system.
