Wire request_id through CallbackInfo for linking by chrsmith · Pull Request #851 · temporalio/api

chrsmith · 2026-08-17T16:56:14Z

⚠️ This is to be merged into the feature/worker-callbacks branch, and not main. Only after the feature is complete will that branch be rebased and merged into main.

This PR makes three changes, all so that resources spanwed from the invocation of a worker callback can be linked correctly.

(1) Remove the Link_NexusOperationCallback variant with a more general Link_Callback proto

Previously we were scoping the feature to only be applicable for SANO callbacks. But if we are going to support worker callbacks for any async operation, having a general link type (that uses the existing Execution proto) will avoid needing to create additional link variants in the future.

(2) Add a callbackpb.CallbackInfo::request_id field

This type is used in the Describe- operations for standalone Activities and standalone Nexus operations. Without it, there would be no way to determine which completion callback is being referred to. (Instead, we couldn't be any more accurate than to have the link point to "one of these N" callbacks.)

(3) Add workflowpb.CallbackInfo::{request_id, result}

The workflowpb namespace forked rather than embedded the callbackpb.CallbackInfo message. The changes here add the missing fields, so that DescribeWorkflowExecution can disambiguate callbacks as well. (In addition to carrying the result of those callbacks.)

Why?

With these changes, the server will be able to properly cross-link resources spawned from completion callbacks.

On the Caller-side, any resources spawned from the completion callbacks would be available on the commonpb.Callback::links field. (*)

queryGetSpawnedResourceLinks(workflowID: string {
DescribeWorkflowExecution(workflowID) {
completion_callbacks {
callback {
links
}
}
}
}

(*) Only the resources initially created from the worker callback invocation will be present. e.g. the Workflow that backs an asynchronous Nexus handler. It would not contain links for any subsequent resources created.

On the Handler-side, a single Link_Callback would be supplied to the Nexus handler receiving the worker callback. (This would be in the form of a nexuspb.Link.)

Breaking changes

Yes, this PR contains breaking proto changes. However, in the context of a PR into a long-lived feature branch for an unshipped feature this is safe. (The protos haven't ever been persisted by a production service.)

Server PR

It isn't out yet, but will be stacked on top of this:
temporalio/temporal#11589

VegetarianOrc · 2026-08-17T17:27:57Z

+ // Source execution the callback was attached to.
+ Execution execution = 1;
+ // Request ID used for the callback's delivery.
+ string request_id = 2;


I think we should consider creating a "callback ID" as fully supported thing. The ambiguity where the request ID can be shared across multiple callbacks feels a little awkward.

Strong +1 to this. We just need a way to uniquely identify a worker callback within the scope of an execution, and having an entirely server-side generated ID removes any potential confusion.
Moreover, having it be an entirely Temporal-managed CallbackInfo::callback_id and not a user-editable Callback::id simplifies things even more.

There's no user-editable callback::id. I'd be more than okay using the request ID as the callback ID since it is a unique identifier as long as we document it.

bergundy · 2026-08-17T20:47:25Z

 // If the state is BLOCKED, blocked reason provides additional information.
 string blocked_reason = 8;

+ // The Request ID used when the Callback was delivered. Used as an idempotency key in case multiple deliveries


I would decouple the user provided request ID from the one the system generates. The start request is not the same as the callback delivery request and those should have different IDs. I would be confused if I saw the same request ID provided in a log for different purposes.

I am concerned that this will be confused with the request ID of the start request used to attach this callback. Document the semantics as we did here:
api/temporal/api/nexus/v1/message.proto
Lines 308 to 311 in 7868510
// Server-generated request ID used as an idempotency token when submitting start requests to
// the handler. Distinct from the request_id in StartNexusOperationRequest, which is the
// caller-side idempotency key for the StartNexusOperation RPC itself.
stringrequest_id=21;

Thanks for linking to the comment, I agree that's exactly how we'd want to define it.

bergundy · 2026-08-17T20:53:50Z

+ // Source execution the callback was attached to.
+ Execution execution = 1;
+ // Request ID used for the callback's delivery.
+ string request_id = 2;


There's no user-editable callback::id. I'd be more than okay using the request ID as the callback ID since it is a unique identifier as long as we document it.

bergundy · 2026-08-17T20:54:56Z

+ // A Nexus operation execution archetype. This is reserved for standalone Nexus operations.
+ EXECUTION_TYPE_NEXUS = 3;
+ // An update workflow execution archtype.
+ EXECUTION_TYPE_UPDATE_WORKFLOW = 4;


This is not an "execution", it's a component within an execution.

bergundy · 2026-08-17T20:55:06Z

 EXECUTION_TYPE_ACTIVITY = 2;
-}
+ // A Nexus operation execution archetype. This is reserved for standalone Nexus operations.
+ EXECUTION_TYPE_NEXUS = 3;


Suggested change
EXECUTION_TYPE_NEXUS = 3;
EXECUTION_TYPE_NEXUS_OPERATION = 3;

chrsmith · 2026-08-18T17:24:34Z

Addressed PR feedback. However, after the blueprint review we will scope worker callbacks to just SANO operations. So I removed the new fields added to workflowpb.CallbackInfo and avoided adding anything else to Link_Callback (which would have been required to support links to callbacks attached to workflow updates).

chrsmith · 2026-08-19T16:50:50Z

I got this all wired up server-side. Will merge so I can rebase things. It'll get another review when I send the feature/worker-callbacks branch out for review before merging into main.

⚠️ This is to be merged into the `feature/worker-callbacks` branch, and not `main`. Only after the feature is complete will that branch be rebased and merged into `main`. --- This PR makes three changes, all so that resources spanwed from the invocation of a worker callback can be linked correctly. (1) Remove the `Link_NexusOperationCallback` variant with a more general `Link_Callback` proto Previously we were scoping the feature to only be applicable for SANO callbacks. But if we are going to support worker callbacks for any async operation, having a general link type (that uses the existing [Execution proto](https://github.com/temporalio/api/blob/0066de621239ca9ddc6c976e091e27a6bc474752/temporal/api/common/v1/message.proto#L73-L77)) will avoid needing to create additional link variants in the future. (2) Add a `callbackpb.CallbackInfo::request_id` field This type is used in the `Describe-` operations for standalone Activities and standalone Nexus operations. Without it, there would be no way to determine _which_ completion callback is being referred to. (Instead, we couldn't be any more accurate than to have the link point to "one of these N" callbacks.) (3) Add `workflowpb.CallbackInfo::{request_id, result}` The `workflowpb` namespace forked rather than embedded the `callbackpb.CallbackInfo` message. The changes here add the missing fields, so that `DescribeWorkflowExecution` can disambiguate callbacks as well. (In addition to carrying the result of those callbacks.) **Why?** With these changes, the server will be able to properly cross-link resources spawned from completion callbacks. On the Caller-side, any resources spawned from the completion callbacks would be available on the `commonpb.Callback::links` field. (*) ```graphql query GetSpawnedResourceLinks(workflowID: string { DescribeWorkflowExecution(workflowID) { completion_callbacks { callback { links } } } } ``` > (*) Only the resources _initially_ created from the worker callback invocation will be present. e.g. the Workflow that backs an asynchronous Nexus handler. It would not contain links for any subsequent resources created. On the Handler-side, a single `Link_Callback` would be supplied to the Nexus handler receiving the worker callback. (This would be in the form of a `nexuspb.Link`.) **Breaking changes** Yes, this PR contains breaking proto changes. However, in the context of a PR into a long-lived feature branch for an unshipped feature this is safe. (The protos haven't ever been persisted by a production service.) **Server PR** It isn't out yet, but will be stacked on top of this: temporalio/temporal#11589

chrsmith requested review from a team as code owners August 17, 2026 16:56

chrsmith requested review from VegetarianOrc and bergundy August 17, 2026 16:57

VegetarianOrc reviewed Aug 17, 2026
View reviewed changes

Wire request_id through CallbackInfo for linking
e5678ad

chrsmith force-pushed the chrsmith/add-request-id-for-linking branch from 79aa66f to e5678adCompare August 17, 2026 19:45

bergundy reviewed Aug 17, 2026
View reviewed changes

Rename request_id to callback_id
7f4fe7f

chrsmith changed the title ~~Wire request_id through CallbackInfo for linking~~Wire callback_id through CallbackInfo for linkingAug 17, 2026

chrsmith changed the title ~~Wire callback_id through CallbackInfo for linking~~Wire request_id through CallbackInfo for linkingAug 17, 2026

chrsmith force-pushed the chrsmith/add-request-id-for-linking branch from 08c0da4 to 18f2186Compare August 18, 2026 17:22

Address PR feedback; Worker callbacks scope
54d5276

chrsmith force-pushed the chrsmith/add-request-id-for-linking branch from 18f2186 to 54d5276Compare August 18, 2026 17:26

Rename to EXECUTION_TYPE_NEXUS_OPERATION
52984c1

chrsmith merged commit 4190870 into feature/worker-callbacksAug 19, 2026
2 checks passed

chrsmith deleted the chrsmith/add-request-id-for-linking branch August 19, 2026 16:50

Navigation Menu

Uh oh!

Wire request_id through CallbackInfo for linking - #851

Wire request_id through CallbackInfo for linking#851
chrsmith merged 4 commits into
feature/worker-callbacksfrom
chrsmith/add-request-id-for-linking

chrsmith commented Aug 17, 2026•
edited
Loading

Uh oh!

VegetarianOrcAug 17, 2026

Uh oh!

chrsmithAug 17, 2026

Uh oh!

bergundyAug 17, 2026

Uh oh!

bergundyAug 17, 2026

Uh oh!

bergundyAug 17, 2026

Uh oh!

chrsmithAug 17, 2026

Uh oh!

bergundyAug 17, 2026

Uh oh!

bergundyAug 17, 2026

Uh oh!

bergundyAug 17, 2026

Uh oh!

chrsmith commented Aug 18, 2026

Uh oh!

chrsmith commented Aug 19, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

	// Server-generated request ID used as an idempotency token when submitting start requests to
	// the handler. Distinct from the request_id in StartNexusOperationRequest, which is the
	// caller-side idempotency key for the StartNexusOperation RPC itself.
	stringrequest_id=21;

	EXECUTION_TYPE_NEXUS = 3;
	EXECUTION_TYPE_NEXUS_OPERATION = 3;

Uh oh!

Conversation

chrsmith commented Aug 17, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

chrsmith commented Aug 18, 2026

Uh oh!

chrsmith commented Aug 19, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

chrsmith commented Aug 17, 2026•
edited
Loading