Worker Deployment Versioning

[Sushisource]

What was changed

Added the annotations and options for worker-deployment-based versioning

Why?

All aboard the versioning train

Checklist

1. Closes [Feature Request] Support New Worker Versioning API #1659

2. How was this tested:
   Added tests

3. Any docs updates needed?

[THardy98]

Didn't really look through the core bridge stuff, maybe worth coordinating on #1638.

For your workflow test files deployment-versioning-no-annotations... there's a workflows directory in test/src that might make more sense for them to be located, instead of directly in test/src.

Just want to re-affirm how this works:

• on the worker, we have the worker's configured deployment version, and the default versioning behaviour for all its workflows
• on the workflow, we can override this versioning behaviour with the newly added workflow definition options (it's a little funky, we're making use of JS's quirk that a function is an object, so a workflow with definition options is a function with properties, as already discussed)
• workflow versioning behaviour is read into the activator (which uses it solely when concluding the activation) and workflow info

Tests were helpful, though I think you probably want someone whose more familiar with the versioning behaviour to take a look

[Sushisource]

This will need to hang out for a bit since I want temporalio/api#579 in before I incorporate that

[mjameswh]

Does this have any value being exported publicly? If yes, then AsyncFunction should also be exported. If not, then please add @internal and @hidden (I will have to experiment a bit more to figure out how to reduce this to a single annotation, but in the mean time, let's use both).

[mjameswh]

Suggested change

	versioningOverride: options.versioningOverride ? options.versioningOverride : undefined,
	versioningOverride: options.versioningOverride ?? undefined,

[mjameswh]

Suggested change

	versioningOverride: opts.versioningOverride ? opts.versioningOverride : undefined,
	versioningOverride: opts.versioningOverride ?? undefined,

[mjameswh]

Seems like those two branches are identical, and in both branches, you ned up making the assignment to activator.workflow anyway. I'd suggest reverting to the original if-elseif-else structure, and move the "workflow definition options" stuff after that whole block.

[mjameswh]

Still a few nits, but no need for another round of review after that. You can safely ignore the unrelated test failures on the feature repo due to protobufjs, as well as the doc publish error due to vercel token needing refresh.

[SamuelMS]

@Sushisource @mjameswh defaultVersioningBehavior is a mandatory option in workerDeploymentOptions, but undefined and UNSPECIFIED aren't accepted as documented here: TS SDK docs and 1.11.5 release

TypeScript sample snippet from the docs:

const myWorker = await Worker.create({
  workflowsPath: require.resolve('./workflows'),
  taskQueue,
  workerDeploymentOptions: {
    useWorkerVersioning: true,
    version: { buildId: '1.0', deploymentName: 'llm_srv' },
    // does not work
    defaultVersioningBehavior: 'UNSPECIFIED',
  },
  connection: nativeConnection,
});

In my use-case, I actually want to set useWorkerVersioning to false – to ignore versioning entirely, but to have online workers self-report in the workflow deployments section of the UI regardless.

TypeScript throws e.g. TS2322: Type undefined is not assignable to type VersioningBehavior, and at runtime you get e.g. Error: Unknown versioning behavior: UNSPECIFIED. Excluding defaultVersioningBehavior entirely throws temporal_sdk_core::worker::workflow: Error while completing workflow activation error=status: InvalidArgument, message: "versioning behavior cannot be specified without deployment options being set with versioned mode", details: [], metadata: MetadataMap { headers: {"content-type": "application/grpc"} } when workflows run.

Let me know if I'm misinterpreting how this is intended to be used, or if you'd like a dedicated issue raised for this.

Thank you!