Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 8 additions & 0 deletions openapi/openapiv2.json
Original file line number Diff line number Diff line change
Expand Up @@ -17808,6 +17808,10 @@
"type": "string",
"format": "int64",
"description": "Monotonic counter reflecting the latest routing decision for this workflow execution.\nUsed for staleness detection between history and matching when dispatching tasks to workers.\nIncremented when a workflow execution routes to a new deployment version, which happens\nwhen a worker of the new deployment version completes a workflow task.\nNote: Pinned tasks and sticky tasks send a value of 0 for this field since these tasks do not\nface the problem of inconsistent dispatching that arises from eventual consistency between\ntask queues and their partitions."
},
"targetWorkerDeploymentVersionOnStart": {
"$ref": "#/definitions/v1WorkerDeploymentVersion",
"description": "The target Worker Deployment Version (from the task queue's routing config) observed on the\nvery first workflow task of this run. On each subsequent workflow task, this value is\ncompared against the current target deployment version, which is fetched from the task queue's routing config,\nto compute the `target_worker_deployment_version_changed` flag in WorkflowTaskStartedEvent. That\nflag signals pinned workflows that the task queue's current deployment version has\nchanged, allowing them to continue-as-new onto the latest version. Without this\nanchor, the comparison falls back to the workflow's effective deployment, which for\npinned workflows permanently differs from the routing target after a version change,\ncausing the flag to stay true indefinitely and triggering infinite continue-as-new\nloops."
}
},
"description": "Holds all the information about worker versioning for a particular workflow execution.\nExperimental. Versioning info is experimental and might change in the future."
Expand Down Expand Up @@ -18179,6 +18183,10 @@
"type": "boolean",
"description": "True if Workflow's Target Worker Deployment Version is different from its Pinned Version and\nthe workflow is Pinned.\nExperimental."
},
"targetWorkerDeploymentVersionOnStart": {
"$ref": "#/definitions/v1WorkerDeploymentVersion",
"description": "The target Worker Deployment Version (from the task queue's routing config) observed on the\nvery first workflow task of this run. On each subsequent workflow task, this value is\ncompared against the current target deployment version, which is fetched from the task queue's routing config,\nto compute the `target_worker_deployment_version_changed` flag in WorkflowTaskStartedEvent."
},
"historySizeBytes": {
"type": "string",
"format": "int64",
Expand Down
22 changes: 22 additions & 0 deletions openapi/openapiv3.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -16658,6 +16658,20 @@ components:
Note: Pinned tasks and sticky tasks send a value of 0 for this field since these tasks do not
face the problem of inconsistent dispatching that arises from eventual consistency between
task queues and their partitions.
targetWorkerDeploymentVersionOnStart:
allOf:
- $ref: '#/components/schemas/WorkerDeploymentVersion'
description: |-
The target Worker Deployment Version (from the task queue's routing config) observed on the
very first workflow task of this run. On each subsequent workflow task, this value is
compared against the current target deployment version, which is fetched from the task queue's routing config,
to compute the `target_worker_deployment_version_changed` flag in WorkflowTaskStartedEvent. That
flag signals pinned workflows that the task queue's current deployment version has
changed, allowing them to continue-as-new onto the latest version. Without this
anchor, the comparison falls back to the workflow's effective deployment, which for
pinned workflows permanently differs from the routing target after a version change,
causing the flag to stay true indefinitely and triggering infinite continue-as-new
loops.
description: |-
Holds all the information about worker versioning for a particular workflow execution.
Experimental. Versioning info is experimental and might change in the future.
Expand Down Expand Up @@ -17070,6 +17084,14 @@ components:
True if Workflow's Target Worker Deployment Version is different from its Pinned Version and
the workflow is Pinned.
Experimental.
targetWorkerDeploymentVersionOnStart:
allOf:
- $ref: '#/components/schemas/WorkerDeploymentVersion'
description: |-
The target Worker Deployment Version (from the task queue's routing config) observed on the
very first workflow task of this run. On each subsequent workflow task, this value is
compared against the current target deployment version, which is fetched from the task queue's routing config,
to compute the `target_worker_deployment_version_changed` flag in WorkflowTaskStartedEvent.
historySizeBytes:
type: string
description: |-
Expand Down
5 changes: 5 additions & 0 deletions temporal/api/history/v1/message.proto
Original file line number Diff line number Diff line change
Expand Up @@ -284,6 +284,11 @@ message WorkflowTaskStartedEventAttributes {
// the workflow is Pinned.
// Experimental.
bool target_worker_deployment_version_changed = 9;
// The target Worker Deployment Version (from the task queue's routing config) observed on the
Copy link
Member Author

Choose a reason for hiding this comment

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

I was initially not going to have this field be present on the TaskStartedAttributes. However, I think this is required since when building the MS back from events, we need this information to be present. Not having this information could cause a workflow, on the passive side, to have a CAN. Again, this can only happen when the user has literally forgotten to have AU as the initial CAN behaviour, but I included this because I think we do need consistency between our active and passive clusters.

happy to be corrected here

Copy link
Contributor

@ShahabT ShahabT Feb 20, 2026

Choose a reason for hiding this comment

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

Not having this information could cause a workflow, on the passive side

This is not relevant anymore with state-based replication. we don't rebuild MS from history anymore for replication, we only do so for reset.

In case of reset it seems we can set the value in MS based on reset time info, right?

I think the better approach is to pass it from the previous run and have it in the wf execution started event. see temporalio/temporal#9374 (comment).

// very first workflow task of this run. On each subsequent workflow task, this value is
// compared against the current target deployment version, which is fetched from the task queue's routing config,
// to compute the `target_worker_deployment_version_changed` flag in WorkflowTaskStartedEvent.
temporal.api.deployment.v1.WorkerDeploymentVersion target_worker_deployment_version_on_start = 10;
// Total history size in bytes, which the workflow might use to decide when to
// continue-as-new regardless of the suggestion. Note that history event count is
// just the event id of this event, so we don't include it explicitly here.
Expand Down
11 changes: 11 additions & 0 deletions temporal/api/workflow/v1/message.proto
Original file line number Diff line number Diff line change
Expand Up @@ -232,6 +232,17 @@ message WorkflowExecutionVersioningInfo {
// face the problem of inconsistent dispatching that arises from eventual consistency between
// task queues and their partitions.
int64 revision_number = 8;
// The target Worker Deployment Version (from the task queue's routing config) observed on the
// very first workflow task of this run. On each subsequent workflow task, this value is
// compared against the current target deployment version, which is fetched from the task queue's routing config,
// to compute the `target_worker_deployment_version_changed` flag in WorkflowTaskStartedEvent. That
// flag signals pinned workflows that the task queue's current deployment version has
// changed, allowing them to continue-as-new onto the latest version. Without this
// anchor, the comparison falls back to the workflow's effective deployment, which for
// pinned workflows permanently differs from the routing target after a version change,
// causing the flag to stay true indefinitely and triggering infinite continue-as-new
// loops.
temporal.api.deployment.v1.WorkerDeploymentVersion target_worker_deployment_version_on_start = 9;
}

// Holds information about ongoing transition of a workflow execution from one deployment to another.
Expand Down
Loading