Skip to content
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

Merged
merged 11 commits into from
Dec 6, 2024

Conversation

Quinn-With-Two-Ns
Copy link
Contributor

Add Nexus Worker interceptor based on the Nexus Java SDK interceptors proposed here nexus-rpc/sdk-java#14

@Quinn-With-Two-Ns
Copy link
Contributor Author

Note: CI will fail until a new Nexus Java SDK is released

Copy link
Member

@cretz cretz left a 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

Comment on lines 38 to 40
EXECUTE_NEXUS_OPERATION("ExecuteNexusOperation"),
START_NEXUS_OPERATION("StartNexusOperation"),
CANCEL_NEXUS_OPERATION("CancelNexusOperation");
Copy link
Member

@cretz cretz Dec 5, 2024

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

Suggested change
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.

Copy link
Contributor Author

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

Copy link
Contributor Author

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

Copy link
Member

@cretz cretz Dec 5, 2024

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.

Copy link
Contributor Author

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

Copy link
Member

@cretz cretz Dec 5, 2024

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.

Copy link
Contributor Author

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

Comment on lines +114 to +116
} finally {
nexusOperationExecuteSpan.finish();
}
Copy link
Member

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?

Copy link
Contributor Author

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)
Copy link
Member

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.

Copy link
Member

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.

Copy link
Contributor Author

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.
Copy link
Member

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?

Comment on lines +107 to +108
StartOperationOutput startOperation(StartOperationInput input)
throws OperationUnsuccessfulException;
Copy link
Member

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.

@Quinn-With-Two-Ns Quinn-With-Two-Ns merged commit 30f391f into temporalio:master Dec 6, 2024
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants