Delivered server-side stream ranges to workflows.

crates/protos/protos/local/temporal/sdk/core/workflow_activation/workflow_activation.proto

@@ -31,7 +31,7 @@ import "temporal/sdk/core/nexus/nexus.proto";
 // 1. init workflow
 // 2. patches
 // 3. random-seed-updates
-// 4. signals/updates
+// 4. signals/updates/channel notifications
 // 5. all others
 // 6. local activity resolutions
 // 7. queries
@@ -41,6 +41,8 @@ import "temporal/sdk/core/nexus/nexus.proto";
 // * Patches are expected to apply to the entire activation
 // * Signal and update handlers should be invoked before workflow routines are iterated. That is to
 //  say before the users' main workflow function and anything spawned by it is allowed to continue.
+// * Channel notifications are input from outside the workflow, like signals, so they go with
+//  them and ahead of the stream ranges among the other jobs.
 // * Local activities resolutions go after other normal jobs because while *not* replaying, they
 //  will always take longer than anything else that produces an immediate job (which is
 //  effectively instant). When *replaying* we need to scan ahead for LA markers so that we can

crates/protos/src/protos/mod.rs

@@ -1962,6 +1962,16 @@ pub mod temporal {
                         }
                     }
 
+                    impl From<workflow_commands::UnsubscribeNotificationChannel> for Attributes {
+                        fn from(s: workflow_commands::UnsubscribeNotificationChannel) -> Self {
+                            Self::UnsubscribeNotificationChannelCommandAttributes(
+                                UnsubscribeNotificationChannelCommandAttributes {
+                                    channel: s.channel,
+                                },
+                            )
+                        }
+                    }
+
                     impl From<workflow_commands::StartTimer> for command::Attributes {
                         fn from(s: workflow_commands::StartTimer) -> Self {
                             Self::StartTimerCommandAttributes(StartTimerCommandAttributes {

crates/sdk-core/CHANGELOG.md

@@ -33,6 +33,19 @@ relevant information.
 
 ## Unreleased
 
+### Added
+* Workflows can subscribe to server-side streams and append batches of records to them with the
+  `SubscribeStream` and `AppendStreamRecords` commands. Consumed ranges reach the workflow as
+  `DeliverStreamRecords` activation jobs, and replay hands each recorded range back in the
+  activation of the task that consumed it.
+* A history fed to a replay worker can carry the stream records its tasks consumed
+  (`HistoryForReplay::with_stream_slices`), so a language replayer that fetched them from the
+  stream service can replay a consuming workflow. History alone holds only the offsets.
+* A task whose history records a consumed range with content that the response carried no
+  records for fails before the workflow runs, rather than after it ran on less input. A legacy
+  query dispatched that way to a worker that no longer holds the run goes unanswered, so the
+  server retries it on the normal task queue, where the records travel with it.
+
 ### Fixed
 * Task-poll targets no longer decrease after cancelled or timed-out polls. Affected pollers still
   retain their slot during backoff, while resource-exhaustion errors still reduce the target.
@@ -68,7 +81,6 @@ relevant information.
   metrics now carry a `failure_reason` attribute. Each is now split into one time series per
   reason, which may affect existing dashboards.
 * Workflow task completions larger than the gRPC request size limit are now paginated automatically when the namespace supports it. Paginated workflow task completions require Temporal Server 1.32.0 or later.
-
 ### Breaking Changes :boom:
 * The following types are now non-exhaustive: `Priority`, `WorkerDeploymentVersion`,
   `WorkerCallbacks`, `WorkflowExecutionInfo`, `ActivityCloseTimeouts`,