Repository navigation
Conversation
A Workflow subscribes with a command and gets the notifications on the scheduled event of its next Workflow Task, so replay sees the same ones. The new values take the first free numbers.
This was referenced Oct 3, 2026
Owner
Author
|
Paused per the 2026-10-05 design review (the decision record is on the proposal page, section 14). Resumes in phase 2 with the CHASM notification work. The branch stays as a pin. |
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 lets a Workflow listen on a notification channel.
What changed?
SubscribeNotificationChannelandUnsubscribeNotificationChannelcommands, each with its own History event and a workflow task failed cause for bad attributes.WorkflowTaskScheduledEventAttributes.notificationscarries what a task wakes on.DescribeWorkflowExecutionResponse.channel_subscriptionslists the run's channels asworkflow/v1.ChannelSubscriptionInfo.openapi/regenerated.Part of AI-198 (epic AI-37).
Why?
The previous PR gives callbacks and pollers a channel. Workflows need it too, and they need it deterministically. So the notifications ride the scheduled event of the task they wake, and replay sees exactly what the run saw. The subscribe and unsubscribe events record when the run started and stopped listening, so replay matches every command to an event. Describe shows where a run stands on each channel, which is the first thing you'd want when one doesn't wake.
How did you test it?
Link to a test plan if any -
make buf-lint,make api-linterandmake http-api-docsare clean. Themake go-grpcoutput builds and vets in a scratch module. The server, Core and Python PRs in the series run workflow subscribe, notify and unsubscribe end to end, replay included.