Users have asked for supporting that invocations from the same call tree are all run on the same revision/deployment. E.g. if service A (revision 12) calls service B, then this call should also run on revision 12. This has the benefit that services wouldn't have to be backward compatible in case revision 13 of service B is deployed in the meantime.
Matching revisions of different services is probably not the best idea since the services could have different revisions (e.g. if service B was introduced later). What could make more sense is to say that a call of a service needs to run on the same deployment (DeploymentId). This has of course the requirement that all dependent services are always deployed together.
A possible challenge with pinning the deployment id of a call tree is that this call tree might be interleaved with other call trees on a newer deployment. Therefore, it can happen that a virtual object instance will be called that has run on a newer revision before and might have evolved the state. Hence, in the general case one probably needs to evolve the state in a backward and forward compatible way.
Users have asked for supporting that invocations from the same call tree are all run on the same revision/deployment. E.g. if service A (revision 12) calls service B, then this call should also run on revision 12. This has the benefit that services wouldn't have to be backward compatible in case revision 13 of service B is deployed in the meantime.
Matching revisions of different services is probably not the best idea since the services could have different revisions (e.g. if service B was introduced later). What could make more sense is to say that a call of a service needs to run on the same deployment (
DeploymentId). This has of course the requirement that all dependent services are always deployed together.A possible challenge with pinning the deployment id of a call tree is that this call tree might be interleaved with other call trees on a newer deployment. Therefore, it can happen that a virtual object instance will be called that has run on a newer revision before and might have evolved the state. Hence, in the general case one probably needs to evolve the state in a backward and forward compatible way.