Versioning3 proto updates for data plane APIs #463
Conversation
| // Workflow automatically moves to the latest version (default build ID of the task queue) when the next | ||
| // task is dispatched. | ||
| VERSIONING_BEHAVIOR_AUTO_UPGRADE = 2; |
There was a problem hiding this comment.
"Auto-upgrade" behavior seemed a better name than "unpinned". But we can change the name later when namings are final. cc @drewhoskins-temporal @antlai-temporal
| temporal.api.enums.v1.VersioningBehavior versioning_behavior = 14; | ||
| // Default versioning behavior that is set at worker server level. | ||
| temporal.api.enums.v1.VersioningBehavior default_versioning_behavior = 15; |
There was a problem hiding this comment.
Asking SDK to send both explicit and default annotations so we can have visibility on what/how users set these.
There was a problem hiding this comment.
|
This all looks good to me from a syntax/consistency POV, but will defer SDK approval to @antlai-temporal. If at all possible, would like to recommend that at least most of the implementation be done server side before this PR is merged to ensure there isn't anything missing. |
|
Thanks @cretz, this is being merged to a feature branch right now. We'll merge it to main once the server implementation is ready. |
What changed?
WorkerVersionStampandWorkerVersionCapabilitiesso this info is sent in the poll requests and task completion commands coming from SDK.versioning_behaviorfield toRespondWorkflowTaskCompletedRequestso SDK can sent the workflow versioning annotation to server when a workflow task completes.build_id,versioning_behavior, anddeployment_namefields toWorkflowExecutionInfo(Mutable State) so server can use the info for routing tasks.Why?
Needed for versioning-3 API.
Breaking changes
None.
Server PR
None.