Conversation
A linked channel names its owner as an execution, a workflow or a standalone activity, so the client needs a typed value for it.
The five calls reach an independent channel or one linked to an execution. Polls return workflow.Notification, so the workflow side shares the type later.
The unit cases fake the service. The live cases skip unless -E names a server that serves channels.
A workflow subscribes by command or listens on its linked channel, and Core hands the notifications over as a job. The handle routes them by kind and ends with unsubscribe().
Describe is how an operator sees what a run listens on and what is pending for it.
The unit cases drive the instance with hand-built activations. The live cases skip unless -E names a channel server, and the linked ones ask the server through the client which kinds it serves.
This was referenced Oct 3, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR adds the notification channel surface to the external-streams branch, the same API the main SDK chain gets.
What changed?
temporalio.common.ExecutionandExecutionType, so a call can name a workflow or a standalone activity as a channel's owner.Clientchannel calls withexecution=and theworkflow_id=shorthand,ChannelAddress,ChannelDescription, the interceptor inputs andworkflow.Notification.workflow.subscribe_channel,workflow.linked_channelandChannelSubscription.unsubscribe(). The runtime routes thenotifications_receivedjob to the handle of the matching kind and puts it with the Signals, so a task knows what woke it before anything resolves.WorkflowExecutionDescription.channel_subscriptionswithChannelSubscriptionInfo.Part of AI-198 (epic AI-37).
Why?
The external runtime will use channels as its wake transport, and a workflow on this branch should reach the same channels a main-SDK workflow does. The text matches the main chain line for line, so the eventual union has one copy of every channel symbol. Two spots differ by design. The runtime keeps a set of the channels it subscribed to and the ones linked to it, and drops a notification nobody asked for. Both are where the external runtime hooks in later. The test probe asks the server through
Client.describe_channelwhich kinds it serves, so these tests don't depend on the external runtime.How did you test it?
Link to a test plan if any -
poe lintis clean, and each commit type-checks on its own. The channel unit cases, the external stream, client and visitor suites, and the worker workflow suite pass on the dev server the fixtures start. Every case intest_channels.pypasses with-Eagainst a server built from the channel chain. That includes the workflow subscribe case, both linked-channel cases and the probe's linked answer.