Conversation
|
|
||
| // The number of attempts made to start/deliver the operation request. | ||
| // This number represents a minimum bound since the attempt is incremented after the request completes. | ||
| int32 attempt = 9; |
There was a problem hiding this comment.
This is attempt to deliver the start request. Will we support overall operation retry in the future? Will this name be confusing if we do? Maybe we should call it start_attempt so that people will not confuse it with activity attempt which has a different meaning.
There was a problem hiding this comment.
I want to keep this for consistency with PendingNexusOperationInfo.
| string request_id = 19; | ||
|
|
||
| // Operation token. Only set for asynchronous operations after a successful StartOperation call. | ||
| string operation_token = 20; |
There was a problem hiding this comment.
I thought we said we didn't want to expose this to callers? They should only have one way of referencing their operations: their caller-side operation ID.
There was a problem hiding this comment.
It's still worth exposing this information as we do for workflow callers.
There was a problem hiding this comment.
I have no horse in this race, but I'm curious, why is it useful to have?
There was a problem hiding this comment.
It's useful for debugging and can be used in the direct Nexus APIs to reattach to the same operation (future capability).
| // The run ID of the operation, useful when run_id was not specified in the request. | ||
| string run_id = 1; | ||
|
|
||
| // Stage to wait for. The operation may be in a more advanced stage when the poll is unblocked. |
There was a problem hiding this comment.
I'm confused, is this the stage the original request sent? Or does it represent the current stage of the operation?
There was a problem hiding this comment.
The current stage. Let me fix the docstring.
| // Updated on terminal status. | ||
| int64 state_transition_count = 10; | ||
| // Updated once on scheduled and once on terminal status. | ||
| int64 state_size_bytes = 11; |
There was a problem hiding this comment.
Is this intentionally a field only present in list? It was mentioned for standalone activities that everything in list was expected to be in describe.
Also, for standalone activities it was mentioned there would be a tool that would make sure everything in list was also in describe result. Can we prioritize that? It's a lot of effort for me to have to continually confirm our assertion on every PR and find these issues since we chose not to reuse types.
There was a problem hiding this comment.
Just want to call this out that we don't have this guarantee for schedules or batch which are much older archetypes: https://github.com/temporalio/api/blob/master/temporal/api/schedule/v1/message.proto https://github.com/temporalio/api/blob/master/temporal/api/workflowservice/v1/request_response.proto#L1715-L1751.
I don't think this guarantee needs to be high priority but we should keep track of it because I do think that it is nice to have. Ideally the SDKs would allow the types to have completely different fields, there's no need to reuse the models here.
There was a problem hiding this comment.
Right, but this guarantee/promise was made as part of not reusing models knowing the SDK will need this guarantee. Was not expecting a "nice to have" guarantee when the promise/guarantee was made.
There was a problem hiding this comment.
Let's take this offline.
There was a problem hiding this comment.
Discussed offline, we will write a tool soon.
| // Response to a successful UnpauseWorkflowExecution request. | ||
| message UnpauseWorkflowExecutionResponse { } | ||
|
|
||
| message StartNexusOperationRequest { |
There was a problem hiding this comment.
Is it intentional we don't have Priority support?
There was a problem hiding this comment.
Yes, priorities only apply to durable matching queues, those are not used for nexus tasks.
# Conflicts: # openapi/openapiv2.json # openapi/openapiv3.yaml # temporal/api/errordetails/v1/message.proto # temporal/api/nexus/v1/message.proto # temporal/api/workflowservice/v1/request_response.proto # temporal/api/workflowservice/v1/service.proto
Co-Authored-By: Claude Opus 4.6 <[email protected]>
Co-Authored-By: Claude Opus 4.6 <[email protected]>
| string blocked_reason = 7; | ||
|
|
||
| // A reason that may be specified in the CancelNexusOpertionRequest. | ||
| string reason = 8; |
There was a problem hiding this comment.
This was set to 24 and I changed it; I don't see why it should be 24.
There was a problem hiding this comment.
(I wonder why we don't have a linter for this?)
There was a problem hiding this comment.
Copy pasta probably. Thanks for catching this.
092ad00 to
d99cea3
Compare
|
|
||
| // How long this operation has been running for, including all attempts and backoff between attempts. | ||
| // Elapsed time from schedule_time to now for running operations or to close_time for closed | ||
| // operations, including all attempts and backoff between attempts. |
There was a problem hiding this comment.
Clarifies it works for running operations (as opposed to NexusOperationListInfo); correct me if that's wrong.
This reverts commit d90a320.
… comment Co-Authored-By: Claude Opus 4.6 <[email protected]>
Co-Authored-By: Claude Opus 4.6 <[email protected]>
Restores the Execution suffix on all Nexus operation types except Link.NexusOperation in common/v1/message.proto. Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
Remove state_size_bytes field and renumber execution_duration. Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
3b976ca to
b314585
Compare
# Conflicts: # openapi/openapiv2.json # openapi/openapiv3.yaml # temporal/api/common/v1/message.proto
| // This is the only timeout settable for a Nexus operation. | ||
| // (-- api-linter: core::0140::prepositions=disabled | ||
| // aip.dev/not-precedent: "to" is used to indicate interval. --) | ||
| google.protobuf.Duration schedule_to_close_timeout = 8; |
There was a problem hiding this comment.
What the other timeouts like schedule to start and start to close
There was a problem hiding this comment.
Will they be in this PR or later?
…-nexus-op-work # Conflicts: # openapi/openapiv2.json
| NEXUS_OPERATION_ID_CONFLICT_POLICY_FAIL = 1; | ||
| // Don't start a new operation; instead return a handle for the running operation. | ||
| NEXUS_OPERATION_ID_CONFLICT_POLICY_USE_EXISTING = 2; | ||
| } |
There was a problem hiding this comment.
We don't support terminate like w/ workflows?
There was a problem hiding this comment.
I'll add that I don't have context for why it's not there; but it seems like something we can always add later if we want to.
There was a problem hiding this comment.
We don't support TERMINATE_IF_RUNNING for anything that isn't workflow.
| bool include_input = 4; | ||
| // Include the outcome (result/failure) in the response if the operation has completed. | ||
| bool include_outcome = 5; | ||
| // Token from a previous DescribeNexusOperationExecutionResponse. If present, long-poll until operation |
There was a problem hiding this comment.
| // Token from a previous DescribeNexusOperationExecutionResponse. If present, long-poll until operation | |
| // Token from a previous DescribeNexusOperationExecutionResponse. If present, this RPC will long-poll until operation |
Took me a minute to understand what this was trying to say w/o this clarification.
There was a problem hiding this comment.
Also does this mean in order to long poll on complete you must make a minimum of two RPCs? One to get the token and one to wait on it? If so what's the use case for the long poll token here instead of just using PollNexusOperationExecutionRequest?
There was a problem hiding this comment.
Polling on DescribeNexusOperationExecution is for the UI. So the UI will describe once to render the page and then long poll so any update can be reflected in the UI.
There was a problem hiding this comment.
fwiw, DescribeActivityExecutionRequest follows the same approach.
Also a noteable difference is, like Quinn alludes to, the Describe returns NexusOperationExecutionInfo which Poll doesn't.
| // - OperationId | ||
| // - RunId | ||
| // - Endpoint | ||
| // - Service | ||
| // - Operation | ||
| // - RequestId | ||
| // - StartTime | ||
| // - ExecutionTime | ||
| // - CloseTime | ||
| // - ExecutionStatus | ||
| // - ExecutionDuration | ||
| // - StateTransitionCount |
There was a problem hiding this comment.
@stephanos can you double check this against the implementation please?
There was a problem hiding this comment.
All but RequestId are supported; fixing that up now: temporalio/temporal#10032
| NEXUS_OPERATION_ID_CONFLICT_POLICY_FAIL = 1; | ||
| // Don't start a new operation; instead return a handle for the running operation. | ||
| NEXUS_OPERATION_ID_CONFLICT_POLICY_USE_EXISTING = 2; | ||
| } |
There was a problem hiding this comment.
We don't support TERMINATE_IF_RUNNING for anything that isn't workflow.
| // The number of attempts made to start/deliver the operation request. | ||
| // This number represents a minimum bound since the attempt is incremented after the request completes. |
There was a problem hiding this comment.
| // The number of attempts made to start/deliver the operation request. | |
| // This number represents a minimum bound since the attempt is incremented after the request completes. | |
| // The number of attempts made to deliver the start operation request. | |
| // This number is approximate, it is incremented when a task is added to the history queue. | |
| // In practice, there could be more attempts if a task is executed but fails to commit, or less attempts if a task was | |
| // never executed. |
There was a problem hiding this comment.
@stephanos please also update this comment for PendingNexusOperationInfo in workflow/v1/message.go.
What changed?
Server PR
temporalio/temporal#9869