Skip to content

Add link field to propagate backlink in signal and signal-with-start responses#761

Merged
long-nt-tran merged 1 commit into
temporalio:masterfrom
long-nt-tran:signals-backlink-api
Apr 14, 2026
Merged

Add link field to propagate backlink in signal and signal-with-start responses#761
long-nt-tran merged 1 commit into
temporalio:masterfrom
long-nt-tran:signals-backlink-api

Conversation

@long-nt-tran
Copy link
Copy Markdown
Contributor

@long-nt-tran long-nt-tran commented Apr 9, 2026

What changed?

Added link fields on SignalWorkflowExecutionResponse and SignalWithStartWorkflowExecutionRequest. I think a singular link should suffice but if reviewers feel otherwise (especially w.r.t. SignalWithStartWorkflowExecutionRequest) let me know.

Why?

To propagate backlinks on signal and signal-with-start executions back to the caller.

Breaking changes

Not a breaking change (unused field)

Server PR

temporalio/temporal#9897

Comment thread temporal/api/workflowservice/v1/request_response.proto Outdated
// Link to be associated with the WorkflowExecutionSignaled event.
// Added on the response to propagate the backlink.
temporal.api.common.v1.Link signal_link = 3;
// Workflow start link to be associated with the WorkflowExecutionStarted event.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would this be propagated back to the caller if the workflow was already started? Seems like that would be confusing. I would call out the behavior in the docstring.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO it should behave like the workflow event link on a normal start workflow, so link to the start if the workflow is started, link to the workflow options update if a callback was attached after the workflow was started.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

commenting for posterity: chatted w/ both offline and we decided to add this in a later PR

@long-nt-tran long-nt-tran force-pushed the signals-backlink-api branch from 5c99d1b to 168fcbb Compare April 10, 2026 22:48
Comment thread temporal/api/workflowservice/v1/request_response.proto
Copy link
Copy Markdown
Member

@bergundy bergundy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved with a small comment.

@long-nt-tran long-nt-tran force-pushed the signals-backlink-api branch from 168fcbb to c7d4e90 Compare April 10, 2026 22:55
@long-nt-tran long-nt-tran force-pushed the signals-backlink-api branch from c7d4e90 to 99f97eb Compare April 13, 2026 17:50
@long-nt-tran long-nt-tran force-pushed the signals-backlink-api branch from 99f97eb to 7111b0b Compare April 14, 2026 21:38
Comment on lines +615 to +617
// The request ID of the Signal request, used by the server to attach this to
// the correct Event ID when generating link.
string request_id = 7;
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

commenting for posterity: discussed offline w/ server, this change (post-server-approval) is ok, see this comment for more details

@long-nt-tran long-nt-tran enabled auto-merge (squash) April 14, 2026 21:40
@long-nt-tran long-nt-tran merged commit ddc38c8 into temporalio:master Apr 14, 2026
4 checks passed
@long-nt-tran long-nt-tran deleted the signals-backlink-api branch April 14, 2026 21:48
long-nt-tran added a commit to temporalio/temporal that referenced this pull request May 15, 2026
## What changed?

### **High level**

With temporalio/api#761 to add the linking on
the Signal and Signal-with-Start responses, This PR adds logic from the
server that:
* Adds `requestID` from Signal and Signal-with-Start requests to the
CHASM workflow tree under a new map field `IncomingSignals`, and event
store, so these requestIDs stay in buffer
* Return a backlink in the response that references the `requestID`
* On buffer flush to the DB transaction, attach these `requestID` to a
concrete `eventID`, which would allow users to later know which event
correlated w/ this request. We will wire the concrete event ID to the
signal request IDs stored in the workflow component CHASM tree
(`IncomingSignals` map)

> [!NOTE]
> Feature is gated behind a new dynamicconfig
`EnableCHASMSignalBacklinks`, which implicitly is only checked if
`EnableChasm` is enabled.

## Why?

This will enable the caller of the signal to have a backlink to the
cross-namespace signal invoked, which will become more relevant for
Nexus SDK ergonomics.

## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [ ] covered by existing tests
- [ ] added new unit test(s)
- [x] added new functional test(s)

In functional tests, I augmented existing tests for Signal and
Signal-with-Start to:
* Ensure that backlink is returned via the responses
* Later use `DescribeWorkflow` to ensure that we get a concrete EventID
(mapped when buffer flushed)
* Multiple signals with the same `requestID` gets de-duped

```
$ go test ./tests/ -run TestLinksTestSuite
ok      go.temporal.io/server/tests     1.486s
```

```
$ go test ./tests/ -run 'TestNexusWorkflowTestSuite' -count=1
ok      go.temporal.io/server/tests     4.714s
```

## Potential risks

Need to test end-to-end to see that the link shows up correctly in the
Web UI.

Feature is gated behind dynamicconfig since it requires CHASM-based
workflow to be enabled.
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.

4 participants