@temporalio/core-bridge 1.9.2 → 1.10.0

package/sdk-core/sdk-core-protos/protos/api_upstream/temporal/api/taskqueue/v1/message.proto

@@ -54,6 +54,29 @@ message TaskQueueMetadata {
     google.protobuf.DoubleValue max_tasks_per_second = 1;
 }
 
+// Used for specifying versions the caller is interested in.
+message TaskQueueVersionSelection {
+    // Include specific Build IDs.
+    repeated string build_ids = 1;
+    // Include the unversioned queue.
+    bool unversioned = 2;
+    // Include all active versions. A version is considered active if it has had new
+    // tasks or polls recently.
+    bool all_active = 3;
+}
+
+message TaskQueueVersionInfo {
+    // Task Queue info per Task Type. Key is the numerical value of the temporal.api.enums.v1.TaskQueueType enum.
+    map<int32, TaskQueueTypeInfo> types_info = 1;
+    temporal.api.enums.v1.BuildIdTaskReachability task_reachability = 2;
+}
+
+message TaskQueueTypeInfo {
+    // Unversioned workers (with `useVersioning=false`) are reported in unversioned result even if they set a Build ID.
+    repeated PollerInfo pollers = 1;
+}
+
+// Deprecated. Use `InternalTaskQueueStatus`. This is kept until `DescribeTaskQueue` supports legacy behavior.
 message TaskQueueStatus {
     int64 backlog_count_hint = 1;
     int64 read_level = 2;
@@ -111,3 +134,96 @@ message BuildIdReachability {
     // Reachability per task queue.
     repeated TaskQueueReachability task_queue_reachability = 2;
 }
+
+message RampByPercentage {
+    // Acceptable range is [0,100).
+    float ramp_percentage = 1;
+}
+
+// These rules assign a Build ID to Unassigned Workflow Executions and
+// Activities.
+//
+// Specifically, assignment rules are applied to the following Executions or
+// Activities when they are scheduled in a Task Queue:
+//    - Generally, any new Workflow Execution, except:
+//      - When A Child Workflow or a Continue-As-New Execution inherits the
+//        Build ID from its parent/previous execution by setting the
+//        `inherit_build_id` flag.
+//      - Workflow Executions started Eagerly are assigned to the Build ID of
+//        the Starter.
+//    - An Activity that is scheduled on a Task Queue different from the one
+//      their Workflow runs on, unless the `use_workflow_build_id` flag is set.
+//
+// In absence of (applicable) redirect rules (`CompatibleBuildIdRedirectRule`s)
+// the task will be dispatched to Workers of the Build ID determined by the
+// assignment rules. Otherwise, the final Build ID will be determined by the
+// redirect rules.
+//
+// When using Worker Versioning, in the steady state, for a given Task Queue,
+// there should typically be exactly one assignment rule to send all Unassigned
+// tasks to the latest Build ID. Existence of at least one such "unconditional"
+// rule at all times is enforce by the system, unless the `force` flag is used
+// by the user when replacing/deleting these rules (for exceptional cases).
+//
+// During a deployment, one or more additional rules can be added to assign a
+// subset of the tasks to a new Build ID based on a "ramp percentage".
+//
+// When there are multiple assignment rules for a Task Queue, the rules are
+// evaluated in order, starting from index 0. The first applicable rule will be
+// applied and the rest will be ignored.
+//
+// In the event that no assignment rule is applicable on a task (or the Task
+// Queue is simply not versioned), the tasks will be sent to unversioned
+// workers, if available. Otherwise, they remain Unassigned, and will be
+// retried for assignment, or dispatch to unversioned workers, at a later time
+// depending on the availability of workers.
+message BuildIdAssignmentRule {
+    string target_build_id = 1;
+
+    // If a ramp is provided, this rule will be applied only to a sample of
+    // tasks according to the provided percentage.
+    // This option can be used only on "terminal" Build IDs (the ones not used
+    // as source in any redirect rules).
+    oneof ramp {
+        // This ramp is useful for gradual Blue/Green deployments (and similar)
+        // where you want to send a certain portion of the traffic to the target
+        // Build ID.
+        RampByPercentage percentage_ramp = 3;
+    }
+}
+
+// These rules apply to tasks assigned to a particular Build ID
+// (`source_build_id`) to redirect them to another *compatible* Build ID
+// (`target_build_id`).
+//
+// It is user's responsibility to ensure that the target Build ID is compatible
+// with the source Build ID (e.g. by using the Patching API).
+//
+// Most deployments are not expected to need these rules, however following
+// situations can greatly benefit from redirects:
+//  - Need to move long-running Workflow Executions from an old Build ID to a
+//    newer one.
+//  - Need to hotfix some broken or stuck Workflow Executions.
+//
+// In steady state, redirect rules are beneficial when dealing with old
+// Executions ran on now-decommissioned Build IDs:
+//  - To redirecting the Workflow Queries to the current (compatible) Build ID.
+//  - To be able to Reset an old Execution so it can run on the current
+//    (compatible) Build ID.
+//
+// Redirect rules can be chained, but only the last rule in the chain can have
+// a ramp.
+message CompatibleBuildIdRedirectRule {
+    string source_build_id = 1;
+    string target_build_id = 2;
+}
+
+message TimestampedBuildIdAssignmentRule {
+    BuildIdAssignmentRule rule = 1;
+    google.protobuf.Timestamp create_time = 2;
+}
+
+message TimestampedCompatibleBuildIdRedirectRule {
+    CompatibleBuildIdRedirectRule rule = 1;
+    google.protobuf.Timestamp create_time = 2;
+}

package/sdk-core/sdk-core-protos/protos/api_upstream/temporal/api/workflow/v1/message.proto

@@ -32,8 +32,10 @@ option ruby_package = "Temporalio::Api::Workflow::V1";
 option csharp_namespace = "Temporalio.Api.Workflow.V1";
 
 import "google/protobuf/duration.proto";
+import "google/protobuf/empty.proto";
 import "google/protobuf/timestamp.proto";
 
+import "temporal/api/enums/v1/common.proto";
 import "temporal/api/enums/v1/workflow.proto";
 import "temporal/api/common/v1/message.proto";
 import "temporal/api/failure/v1/message.proto";
@@ -57,6 +59,37 @@ message WorkflowExecutionInfo {
     int64 history_size_bytes = 15;
     // If set, the most recent worker version stamp that appeared in a workflow task completion
     temporal.api.common.v1.WorkerVersionStamp most_recent_worker_version_stamp = 16;
+    // Workflow execution duration is defined as difference between close time and execution time.
+    // This field is only populated if the workflow is closed.
+    google.protobuf.Duration execution_duration = 17;
+    // Contains information about the root workflow execution.
+    // The root workflow execution is defined as follows:
+    // 1. A workflow without parent workflow is its own root workflow.
+    // 2. A workflow that has a parent workflow has the same root workflow as its parent workflow.
+    // Note: workflows continued as new or reseted may or may not have parents, check examples below.
+    //
+    // Examples:
+    //   Scenario 1: Workflow W1 starts child workflow W2, and W2 starts child workflow W3.
+    //     - The root workflow of all three workflows is W1.
+    //   Scenario 2: Workflow W1 starts child workflow W2, and W2 continued as new W3.
+    //     - The root workflow of all three workflows is W1.
+    //   Scenario 3: Workflow W1 continued as new W2.
+    //     - The root workflow of W1 is W1 and the root workflow of W2 is W2.
+    //   Scenario 4: Workflow W1 starts child workflow W2, and W2 is reseted, creating W3
+    //     - The root workflow of all three workflows is W1.
+    //   Scenario 5: Workflow W1 is reseted, creating W2.
+    //     - The root workflow of W1 is W1 and the root workflow of W2 is W2.
+    temporal.api.common.v1.WorkflowExecution root_execution = 18;
+    // The currently assigned build ID for this execution. Presence of this value means worker versioning is used
+    // for this execution. Assigned build ID is selected based on Worker Versioning Assignment Rules
+    // when the first workflow task of the execution is scheduled. If the first workflow task fails and is scheduled
+    // again, the assigned build ID may change according to the latest versioning rules.
+    // Assigned build ID can also change in the middle of a execution if Compatible Redirect Rules are applied to
+    // this execution.
+    string assigned_build_id = 19;
+    // Build ID inherited from a previous/parent execution. If present, assigned_build_id will be set to this, instead
+    // of using the assignment rules.
+    string inherited_build_id = 20;
 }
 
 message WorkflowExecutionConfig {
@@ -79,6 +112,20 @@ message PendingActivityInfo {
     google.protobuf.Timestamp expiration_time = 10;
     temporal.api.failure.v1.Failure last_failure = 11;
     string last_worker_identity = 12;
+    // Absence of `assigned_build_id` generally means this task is on an "unversioned" task queue.
+    // In rare cases, it can also mean that the task queue is versioned but we failed to write activity's
+    // independently-assigned build ID to the database. This case heals automatically once the task is dispatched.
+    oneof assigned_build_id {
+        // When present, it means this activity is assigned to the build ID of its workflow.
+        google.protobuf.Empty use_workflow_build_id = 13;
+        // This means the activity is independently versioned and not bound to the build ID of its workflow.
+        // The activity will use the build id in this field instead.
+        // If the task fails and is scheduled again, the assigned build ID may change according to the latest versioning
+        // rules.
+        string last_independently_assigned_build_id = 14;
+    }
+    // The version stamp of the worker to whom this activity was most recently dispatched
+    temporal.api.common.v1.WorkerVersionStamp last_worker_version_stamp = 15;
 }
 
 message PendingChildExecutionInfo {
@@ -152,3 +199,90 @@ message NewWorkflowExecutionInfo {
     temporal.api.common.v1.Header header = 13;
 }
 
+// CallbackInfo contains the state of an attached workflow callback.
+message CallbackInfo {
+    // Trigger for when the workflow is closed.
+    message WorkflowClosed {}
+
+    message Trigger {
+        oneof variant {
+            WorkflowClosed workflow_closed = 1;
+        }
+    }
+
+    // Information on how this callback should be invoked (e.g. its URL and type).
+    temporal.api.common.v1.Callback callback = 1;
+    // Trigger for this callback.
+    Trigger trigger = 2;
+    // The time when the callback was registered.
+    google.protobuf.Timestamp registration_time = 3;
+
+    temporal.api.enums.v1.CallbackState state = 4;
+    // The number of attempts made to deliver the callback.
+    // This number represents a minimum bound since the attempt is incremented after the callback request completes.
+    int32 attempt = 5;
+
+    // The time when the last attempt completed.
+    google.protobuf.Timestamp last_attempt_complete_time = 6;
+    // The last attempt's failure, if any.
+    temporal.api.failure.v1.Failure last_attempt_failure = 7;
+    // The time when the next attempt is scheduled.
+    google.protobuf.Timestamp next_attempt_schedule_time = 8;
+}
+
+// PendingNexusOperationInfo contains the state of a pending Nexus operation.
+message PendingNexusOperationInfo {
+    // Endpoint name.
+    // Resolved to a URL via the cluster's endpoint registry.
+    string endpoint = 1;
+    // Service name.
+    string service = 2;
+    // Operation name.
+    string operation = 3;
+
+    // Operation ID. Only set for asynchronous operations after a successful StartOperation call.
+    string operation_id = 4;
+
+    // Schedule-to-close timeout for this operation.
+    // This is the only timeout settable by a workflow.
+    // (-- api-linter: core::0140::prepositions=disabled
+    //     aip.dev/not-precedent: "to" is used to indicate interval. --)
+    google.protobuf.Duration schedule_to_close_timeout = 5;
+
+    // The time when the operation was scheduled.
+    google.protobuf.Timestamp scheduled_time = 6;
+
+    temporal.api.enums.v1.PendingNexusOperationState state = 7;
+
+    // The number of attempts made to deliver the start operation request.
+    // This number represents a minimum bound since the attempt is incremented after the request completes.
+    int32 attempt = 8;
+
+    // The time when the last attempt completed.
+    google.protobuf.Timestamp last_attempt_complete_time = 9;
+    // The last attempt's failure, if any.
+    temporal.api.failure.v1.Failure last_attempt_failure = 10;
+    // The time when the next attempt is scheduled.
+    google.protobuf.Timestamp next_attempt_schedule_time = 11;
+
+    NexusOperationCancellationInfo cancellation_info = 12;
+}
+
+// NexusOperationCancellationInfo contains the state of a nexus operation cancellation.
+message NexusOperationCancellationInfo {
+    // The time when cancellation was requested.
+    google.protobuf.Timestamp requested_time = 1;
+
+    temporal.api.enums.v1.NexusOperationCancellationState state = 2;
+
+    // The number of attempts made to deliver the cancel operation request.
+    // This number represents a minimum bound since the attempt is incremented after the request completes.
+    int32 attempt = 3;
+
+    // The time when the last attempt completed.
+    google.protobuf.Timestamp last_attempt_complete_time = 4;
+    // The last attempt's failure, if any.
+    temporal.api.failure.v1.Failure last_attempt_failure = 5;
+    // The time when the next attempt is scheduled.
+    google.protobuf.Timestamp next_attempt_schedule_time = 6;
+}