Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add data plane fields w/ renamed Worker Versioning concepts #514

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

ShahabT
Copy link
Contributor

@ShahabT ShahabT commented Jan 14, 2025

READ BEFORE MERGING: All PRs require approval by both Server AND SDK teams before merging! This is why the number of required approvals is "2" and not "1"--two reviewers from the same team is NOT sufficient. If your PR is not approved by someone in BOTH teams, it may be summarily reverted.

What changed?
The following concepts in Worker Versioning V3 is being renamed. This PR adds the data plane fields with new names so SDK can populate them like the old ones.
DeploymentSeries -> WorkerDeployment
Deployment -> WorkerDeploymentVersion

Also WorkerVersionCapabilities and its use_versioning boolean are replaced with WorkerDeploymentOptions and WorkflowVersioningMode enum to be more compatible with V3 changes and also extensible in the future.

RespondActivityTask*Request used to send deployment but that is now deprecated. Since Server does not have any anticipated use for these values, I did not add a replacement for them at the moment.

Why?
See ^^

Breaking changes
Not breaking, some things are deprecated that will be cleaned up at a later time with other old Versioning stuff.

Server PR
Server PR will follow soon. But these changes should not break server compile because methods are not touched.

@ShahabT ShahabT requested review from a team as code owners January 14, 2025 23:51
Copy link
Member

@cretz cretz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

General concerns about deprecating so many things a few weeks after merging it. I just want to make sure we understand the consequences of ever removing API.

But only change requested is to add deprecated options.

@@ -251,11 +251,20 @@ message WorkflowTaskCompletedEventAttributes {
// The deployment that completed this task. May or may not be set for unversioned workers,
// depending on whether a value is sent by the SDK. This value updates workflow execution's
// `versioning_info.deployment`.
// Deprecated. Replaced with `deployment_name` and `deployment_version`.
Copy link
Member

@cretz cretz Jan 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I admit I am a bit concerned about the idea of removing this later. This was just merged a couple months ago and now it's being deprecated.

It is very important we try our best not to make backwards incompatible changes to released API, even if we think it is unused. Customers build proxies and have code generators and in general have stability expectations on our API. We have broken users in the past by making incompatible changes to API (again, even if unused by our SDKs as our SDKs are not the only ones that expect API stability). This strive for API stability includes pre-release/public-preview API because unlike SDKs, we cannot make assumptions about downstream consumption.

Also, if this field is ever set, removing this will make history JSON incompatible and we strive to make history always backwards (and forwards) compatible even pre-release/public-preview histories.

@@ -251,11 +251,20 @@ message WorkflowTaskCompletedEventAttributes {
// The deployment that completed this task. May or may not be set for unversioned workers,
// depending on whether a value is sent by the SDK. This value updates workflow execution's
// `versioning_info.deployment`.
// Deprecated. Replaced with `deployment_name` and `deployment_version`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add [deprecated = true]; to all deprecated fields?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants