-
Notifications
You must be signed in to change notification settings - Fork 78
[DO NOT MERGE] Add standalone activity APIs #640
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
base: master
Are you sure you want to change the base?
Changes from all commits
f1545cf
bf17726
eb87a8b
c037d86
04d0192
3440497
905e783
7c75f27
b230cb1
212b347
c08b7a8
6a97b11
7d4994e
7ce1df6
91d94b6
aea964b
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Large diffs are not rendered by default.
Large diffs are not rendered by default.
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,68 @@ | ||
| syntax = "proto3"; | ||
|
|
||
| package temporal.api.enums.v1; | ||
|
|
||
| option go_package = "go.temporal.io/api/enums/v1;enums"; | ||
| option java_package = "io.temporal.api.enums.v1"; | ||
| option java_multiple_files = true; | ||
| option java_outer_classname = "ActivityProto"; | ||
| option ruby_package = "Temporalio::Api::Enums::V1"; | ||
| option csharp_namespace = "Temporalio.Api.Enums.V1"; | ||
|
|
||
| // Status of a standalone activity. | ||
| // The status is updated once, when the activity is originally scheduled, and again when the activity reaches a terminal | ||
| // status. | ||
| // TODO: Should this be a common execution status? Seems like the other archetypes will share this status. | ||
| // (-- api-linter: core::0216::synonyms=disabled | ||
| // aip.dev/not-precedent: Named consistently with WorkflowExecutionStatus. --) | ||
| enum ActivityExecutionStatus { | ||
| ACTIVITY_EXECUTION_STATUS_UNSPECIFIED = 0; | ||
| // The activity is not in a terminal status. This does not necessarily mean that there is a currently running | ||
| // attempt. The activity may be backing off between attempts or waiting for a worker to pick it up. | ||
| ACTIVITY_EXECUTION_STATUS_RUNNING = 1; | ||
|
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We will likely add a
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think either are a wise direction. What is happening between "running" and "done" are not traditionally execution statuses. Are you going to have a "backing off" status too? Execution status has traditionally been "running or done", and this changes those expectations unnecessarily. Can you use a separate enum to provide more detailed information about the state the running activity/workflow is in and leave the execution status alone?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That's what we are doing for workflow pause, we should be consistent for any type of execution.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Right, I am saying we shouldn't do it for workflow pause either (and have mentioned it in those situations too). It's the same reason that "backing off" doesn't need to be a status. Sure it is effectively paused during backoff, but that doesn't affect that Temporal defines activities and workflows as running if they are not completed. There are many many cases where the expectations would be violated. For instance, people expect ID reuse policy to only apply to not-running workflows, and ID conflict policy to only apply to running workflows. This violates both of those. People expect
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it'd really nice to be able to see paused executions and their counts in the main list view. I don't think "backing off" is the same as pause, we don't update visibility and don't have enough of an incentive to do that for intermediate transient states. In any case, we shouldn't be having this debate here. Whatever we decide to do for workflows we will copy to activities. For now, we are not even implementing standalone activity pause. That will likely come in the second phase of this project.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Sure, but that doesn't mean affecting existing fields/concepts like status that have a clear defined expectation and always have
👍 |
||
| // The activity completed successfully. | ||
| ACTIVITY_EXECUTION_STATUS_COMPLETED = 2; | ||
| // The activity completed with failure. | ||
| ACTIVITY_EXECUTION_STATUS_FAILED = 3; | ||
| // The activity completed as canceled. | ||
| // Requesting to cancel an activity does not automatically transition the activity to canceled status. If the | ||
| // activity has a currently running attempt, the activity will only transition to canceled status if the current | ||
| // attempt is unsuccessful. | ||
| // TODO: Clarify what happens if there are no more allowed retries after the current attempt. | ||
| ACTIVITY_EXECUTION_STATUS_CANCELED = 4; | ||
| // The activity was terminated. Termination does not reach the worker and the activity code cannot react to it. | ||
| // A terminated activity may have a running attempt and will be requested to be canceled by the server when it | ||
| // heartbeats. | ||
| ACTIVITY_EXECUTION_STATUS_TERMINATED = 5; | ||
| // The activity has timed out by reaching the specified shedule-to-start or schedule-to-close timeouts. | ||
| // TODO: Clarify if there are other conditions where the activity can end up in timed out status. | ||
| ACTIVITY_EXECUTION_STATUS_TIMED_OUT = 6; | ||
| } | ||
|
|
||
| // Defines whether to allow re-using an activity ID from a previously *closed* activity. | ||
| // If the request is denied, the server returns an `ActivityExecutionAlreadyStarted` error. | ||
| // | ||
| // See `ActivityIdConflictPolicy` for handling ID duplication with a *running* activity. | ||
| enum ActivityIdReusePolicy { | ||
| ACTIVITY_ID_REUSE_POLICY_UNSPECIFIED = 0; | ||
| // Always allow starting an activity using the same activity ID. | ||
| ACTIVITY_ID_REUSE_POLICY_ALLOW_DUPLICATE = 1; | ||
| // Allow starting an activity using the same ID only when the last activity's final state is one | ||
| // of {failed, canceled, terminated, timed out}. | ||
| ACTIVITY_ID_REUSE_POLICY_ALLOW_DUPLICATE_FAILED_ONLY = 2; | ||
| // Do not permit re-use of the ID for this activity. Future start requests could potentially change the policy, | ||
| // allowing re-use of the ID. | ||
| ACTIVITY_ID_REUSE_POLICY_REJECT_DUPLICATE = 3; | ||
| } | ||
|
|
||
| // Defines what to do when trying to start an activity with the same ID as a *running* activity. | ||
| // Note that it is *never* valid to have two running instances of the same activity ID. | ||
| // | ||
| // See `ActivityIdReusePolicy` for handling activity ID duplication with a *closed* activity. | ||
| enum ActivityIdConflictPolicy { | ||
| ACTIVITY_ID_CONFLICT_POLICY_UNSPECIFIED = 0; | ||
| // Don't start a new activity; instead return `ActivityExecutionAlreadyStarted` error. | ||
| ACTIVITY_ID_CONFLICT_POLICY_FAIL = 1; | ||
| // Don't start a new activity; instead return a handle for the running activity. | ||
| ACTIVITY_ID_CONFLICT_POLICY_USE_EXISTING = 2; | ||
| } | ||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why inconsistently make these as fields instead of search attributes like workflow? Are they also in search attributes, or are we just forbidding the use of this information in queries for activities even though we allow it for workflows? By making them fields, we are ensuring that list and describe field behaviors diverge for the same field which is confusing to have to explain for the same field name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is available for workflows though...
api/temporal/api/workflow/v1/message.proto
Lines 43 to 45 in 1ae5b67
Search attributes returned here are custom ones provided by the user in the start request.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah I was confused by the name list info here and not there (I probably won't be the last to be confused by this inconsistency). There are other mismatched fields though, but can bring those up separately.