-
Notifications
You must be signed in to change notification settings - Fork 152
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
Add Nexus Worker interceptor #2278
Add Nexus Worker interceptor #2278
Conversation
b7e91c4
to
4102533
Compare
Note: CI will fail until a new Nexus Java SDK is released |
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.
Looks great, only one minor span naming thing worth discussing
EXECUTE_NEXUS_OPERATION("ExecuteNexusOperation"), | ||
START_NEXUS_OPERATION("StartNexusOperation"), | ||
CANCEL_NEXUS_OPERATION("CancelNexusOperation"); |
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.
To match other span names, I wonder if this should be
EXECUTE_NEXUS_OPERATION("ExecuteNexusOperation"), | |
START_NEXUS_OPERATION("StartNexusOperation"), | |
CANCEL_NEXUS_OPERATION("CancelNexusOperation"); | |
START_NEXUS_OPERATION("StartNexusOperation"), | |
RUN_NEXUS_OPERATION("RunNexusOperation"), | |
CANCEL_NEXUS_OPERATION("CancelNexusOperation"); |
It seems we use "start" for outbound things and "run" for inbound things. I would usually not consider this a blocker, but we copy these names in the other SDKs too.
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.
Yes I was inconsistent here since the handler side is called startOperation
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.
in the future we will have types like GetResult
or GetInfo
so I think the types here should reflect the method being called
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.
Yes I was inconsistent here since the handler side is called startOperation
My concern is more about the user consistency than the method names. We have interceptor names called start
for start workflow but execute
for starting child workflow, so we are inconsistent anyways there.
But we have outbound spans for starting workflow, starting activity, starting child workflow, and now starting Nexus operation. I think calling all of those "Start" spans is reasonable from the caller side. And we have inbound spans for running workflow, running activity, and now running Nexus operation, so "Run" is reasonable there. I can understand that both child workflows and Nexus operations may not complete their work in the span (this behavior is different in each SDK), but still is a "Run" in the sense that it's an implementation side thing as opposed to "Start" which is a caller side thing.
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.
But unlike activities the Nexus operation is not being "Run" in this span, it is simply being started. if we wanted to keep the Run
prefix I would be OK with StartNexusOperation
-> RunStartNexusOperation
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.
I think the same thing happens to child workflows though, especially with sticky disabled, and especially in SDKs that do not recreate this span during replay. The operation is being run, it just may say it's not completing yet. I think we would have to use at least RunStartNexusOperation
since StartNexusOperation
is for the caller side. Not the biggest fan, but it's at least a bit more consistent.
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.
I think it is a bit different because nexus handlers are not trying to look like durable execution
} finally { | ||
nexusOperationExecuteSpan.finish(); | ||
} |
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.
Remind me again when this finally
block is hit in Java? Is this after the operation completes or after the request to schedule it has been sent?
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.
After the request to schedule it has been sent, we do the same thing for activities and child workflows in the Java SDK open tracing interceptor
SpanCreationContext context = | ||
SpanCreationContext.newBuilder() | ||
.setSpanOperationType(SpanOperationType.START_NEXUS_OPERATION) | ||
.setActionName(serviceName + "." + operationName) |
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.
I wonder if it'd be better to use a slash for the delimiter. That's the standard for gRPC services and likely will be the same for Nexus.
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.
I think this may be an opportunity for Nexus spec to define what a single-string qualified operation name looks like. I think I like slash because that represents how it looks in a URL. I also think we should consider disallowing slashes (and maybe other non-url-safe characters) in operation names, but that's not that important.
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.
Going with /
for now, can resist since we are still not GA and this is the open tracing interceptor
@@ -0,0 +1,198 @@ | |||
/* | |||
* Copyright (C) 2022 Temporal Technologies, Inc. All Rights Reserved. |
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.
Don't you want to update the year?
StartOperationOutput startOperation(StartOperationInput input) | ||
throws OperationUnsuccessfulException; |
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.
I wonder if this shouldn't follow the operation handler interface but I understand that what you have here is more consistent with Temporal interceptors.
7212c59
to
b6e8ba6
Compare
Add Nexus Worker interceptor based on the Nexus Java SDK interceptors proposed here nexus-rpc/sdk-java#14