restatedev
Deprecate service protocol <= 4
Proposed deprecation strategy for service protocol <= 4:
- We start printing a warning in
1.4every time users try to use an SDK using protocol <= v4. - We phase out support in 1.x (to be decided), completely removing support for old SDKs. In that case, invocations will simply panic, asking user to rollback to previous runtime version to complete those invocations (or kill them).
- We start printing a warning in 1.4 every time users try to use an SDK using protocol <= v4.
What does every time mean in your opinion? I would not print on every invocation because this will clutter the logs significantly. Instead we can log it on start-up or periodically.
In general, I am +1 for this approach. How are we gonna decide on when to remove support? Maybe we should check on Discord and Slack whether users are still using the old SDKs and require support for them.
I would not print on every invocation because this will clutter the logs significantly. Instead we can log it on start-up or periodically.
I would do it exactly every invocation so the log gets cluttered and people will notice.
How are we gonna decide on when to remove support?
I think we can be very much arbitrary here and simply say in two or three releases (~6 months) we remove it. Sampling Discord and Slack IMO just gives us a too small audience sample. We also have download statistics, those might help.
As an intermediate step we could in 1.5 to stop allowing people to register deployments using the old SDKs... Basically return an error in that case saying "you can't register a deployment with a protocol version <= 3"
I think an even better place to print such warnings would be from the restate CLI - the services and deployments subcommands specifically should inform the operator about deployments using deprecated SDKs. Operators must be able to easily audit their deployments prior to starting an upgrade.
@slinkydeveloper I tried adding the warning to the UI, but I only have access to the deployment protocol version once the deployment is registered, which I think it's too late. Ideally, we should get the protocol version during the dry_run registration.
@nikrooz checkout https://github.com/restatedev/restate/pull/3220, it should give you what you need.
From Restate 1.6 we should prevent executing new requests to SDKs using the old protocol. In case of service to service communication, this will be a retryable error and not a terminal failure.
Because we prevent executing new requests to the old SDKs, we won't need to initialize journal table v1 anymore. Hence, we should flip the default behavior where for new invocations we initialize table v1, and remove the "migration v1 -> v2", since now only these two cases will be possible:
- Invocation already exists on table v1 -> go to completion
- New invocations or existing invocations -> always go to table v2
In order to do that, we probably need some way for leaders and replicas to agree. @AhmedSoliman how do we sort this point out?
For leaders and replicas to agree, this will be the process:
- in 1.6 we need to introduce a new feature flag in the state machine to enable using the journal v2 table by default, but we don't enable it yet (still keep it behind feature flag for testing purposes)
- in 1.7 we enable this feature flag by default, by leaders self proposing it.
cc @tillrohrmann i can take care of the work needed in 1.6 for this.