[Jetty] Added the Workflow Activity owner to streams.

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

@@ -132,29 +132,36 @@ enum StreamOwnerKind {
   STREAM_OWNER_KIND_WORKFLOW = 1;
   // A standalone Activity run. It is a chain of one run, so its streams end with the run.
   STREAM_OWNER_KIND_ACTIVITY = 2;
+  // An Activity that a Workflow run scheduled. It is a chain of one, keyed by the scheduling run
+  // and the Activity id, so its streams end with the Activity.
+  STREAM_OWNER_KIND_WORKFLOW_ACTIVITY = 3;
 }
 
 // One stream, a topic of an owner in a namespace.
 message StreamAddress {
   string namespace = 1;
   StreamOwnerKind owner_kind = 2;
-  // The owning Workflow. Empty for an Activity owner.
+  // The owning Workflow, or the Workflow that scheduled a Workflow Activity. Empty for a
+  // standalone Activity owner.
   string workflow_id = 3;
   // Pins the stream to the run chain that holds this run. Empty follows the chain that holds the
   // Workflow id when the call starts. For an Activity owner, the Activity run, and empty names
-  // the newest run of the Activity id when the call starts.
+  // the newest run of the Activity id when the call starts. For a Workflow Activity owner, the
+  // run that scheduled the Activity. It is required, since an Activity id names nothing across
+  // runs.
   string run_id = 4;
   string topic = 5;
-  // The owning standalone Activity. Empty for a Workflow owner.
+  // The owning Activity. Empty for a Workflow owner.
   string activity_id = 6;
 }
 
 // A Workflow's run chain. Its streams are keyed by its first run, so they follow
 // Continue-as-New, and a new chain on the same Workflow id gets streams of its own. A standalone
-// Activity run is a chain of one run, with the run as `first_run_id`.
+// Activity run is a chain of one run, with the run as `first_run_id`. A Workflow Activity is a
+// chain of one, with the scheduling run as `first_run_id`.
 message ChainId {
   string namespace = 1;
-  // Empty for an Activity owner.
+  // Empty for a standalone Activity owner.
   string workflow_id = 2;
   string first_run_id = 3;
   // `UNSPECIFIED` is a Workflow owner, so a chain from before the Activity kind stays valid.
@@ -448,7 +455,8 @@ message RunStreamDriverResponse {}
 message DeleteOwnerRequest {
   string namespace = 1;
   StreamOwnerKind owner_kind = 2;
-  // The Workflow whose streams go, for a Workflow owner.
+  // The Workflow whose streams go, for a Workflow owner. The streams of every Activity that the
+  // Workflow scheduled go too.
   string workflow_id = 3;
   // The standalone Activity whose streams go, across all its runs, for an Activity owner.
   string activity_id = 4;

crates/sdk-core/CHANGELOG.md

@@ -172,6 +172,34 @@ relevant information.
   fits 53 bits and a JSON number holds it exactly. The Nexus contract's models and JavaScript
   refused the earlier 16-bit form. A start time from May 2109 on is refused. The vector file
   holds the new keys.
+* Experimental: the stream protos name a Workflow Activity owner. `StreamOwnerKind` gains
+  `WORKFLOW_ACTIVITY`, an Activity that a Workflow run scheduled. Its `StreamAddress` and
+  `ChainId` set `workflow_id`, the scheduling run and `activity_id`, with no new field. The
+  vendored API's owner kind gains `WORKFLOW_ACTIVITY`. Core still refuses the kind as
+  `UNSUPPORTED`.
+* Experimental: a Workflow Activity owns streams. Its `StreamAddress` names the Workflow, the
+  scheduling run and the Activity id, all required. It is a chain of one, keyed by that run, so
+  Activity `1` of the next run after Continue-as-New is another stream. Core describes the run
+  and looks up the Activity in `pending_activities`. A closed run ends reads at once. A running
+  run that no longer lists the Activity ends reads only after the owner start grace from the
+  first check that found it so, and refuses producers at once. Cursors hash under the kind
+  `workflow_activity` with the run in the owner id. The Redis keys have the hash tag
+  `{<namespace>:!wa:<workflow id>:<run id>:<activity id>}`, and the append script (hashes
+  `eec20388`, and `418b9d10` with the notification log) adds each log key to the chain's
+  `topics` set on a producer attempt's first batch. `StreamStore::written_topics` answers that
+  set, and every store and wrapper must implement it. A Workflow's `DeleteOwner` also deletes
+  its Activities' streams. `OwnerId` gains `WorkflowActivity` and `OwnerStatus` gains
+  `ActivityGone`. The documented Redis ACL gains `+sadd +smembers`.
+* Experimental: the scheduling Workflow's Core closes a Workflow Activity's streams when it
+  resolves the Activity. Workflow code marks the Activity with the `ScheduleActivity` header
+  `__temporal_stream_owner`. When a marked Activity resolves outside replay, Core closes each
+  topic in the Activity's topic set in the background, once the activation completed and its
+  stream output was appended. A completed Activity closes with a null result, and a failed,
+  timed-out or canceled one with the failure its resolution holds, cut to `MAX_CLOSE_BYTES`. The
+  close names `<activity id>@<run id>` as `closed_by` and reaches the stream's notifier. A close
+  that fails is logged and does not fail the Workflow Task. Unmarked Activities cost no store
+  call. Notifier calls name a Workflow Activity stream by its Workflow, scheduling run and
+  Activity id.
 
 ### Breaking Changes
 * Replay detects changes to the service or operation of scheduled Nexus operations, reporting