Add signal/activities and rename interceptor feature (#354)

features/features.go

@@ -38,8 +38,8 @@ import (
 	update_activities "github.com/temporalio/features/features/update/activities"
 	update_async_accepted "github.com/temporalio/features/features/update/async_accepted"
 	update_basic "github.com/temporalio/features/features/update/basic"
+	update_client_interceptor "github.com/temporalio/features/features/update/client_interceptor"
 	update_deduplication "github.com/temporalio/features/features/update/deduplication"
-	update_intercept "github.com/temporalio/features/features/update/intercept"
 	update_non_durable_reject "github.com/temporalio/features/features/update/non_durable_reject"
 	update_self "github.com/temporalio/features/features/update/self"
 	update_task_failure "github.com/temporalio/features/features/update/task_failure"
@@ -89,7 +89,7 @@ func init() {
 		update_async_accepted.Feature,
 		update_basic.Feature,
 		update_deduplication.Feature,
-		update_intercept.Feature,
+		update_client_interceptor.Feature,
 		update_non_durable_reject.Feature,
 		update_self.Feature,
 		update_task_failure.Feature,

features/signal/activities/README.md

@@ -0,0 +1,8 @@
+# Run activities from within a Workflow Signal
+
+Workflows can run activities from within a Signal handler.
+
+# Detailed spec
+
+Workflow Signal handlers are like workflow code in that they can invoke and wait on activities.
+This test invokes a number of activities within the Signal and blocks on them, returning from the Signal when they have all completed.

features/signal/activities/feature.ts

@@ -0,0 +1,38 @@
+import { Feature } from '@temporalio/harness';
+import * as wf from '@temporalio/workflow';
+import * as assert from 'assert';
+
+const mySignal = wf.defineSignal<any[]>('mySignal');
+const activityCount = 5;
+const activityResult = 6;
+
+const activitiesImpl = {
+  async myActivity(): Promise<number> {
+    return activityResult;
+  },
+};
+
+const activities = wf.proxyActivities<typeof activitiesImpl>({
+  startToCloseTimeout: '5s',
+});
+
+export const feature = new Feature({
+  workflow,
+  activities: activitiesImpl,
+  checkResult: async (_, handle) => {
+    await handle.signal(mySignal);
+    const result = await handle.result();
+    assert.equal(result, activityResult * activityCount);
+  },
+});
+
+export async function workflow(): Promise<number> {
+  let total = 0;
+  wf.setHandler(mySignal, async () => {
+    const promises = Array.from({ length: activityCount }, activities.myActivity);
+    const counts = await Promise.all(promises);
+    total = counts.reduce((a, b) => a + b, 0);
+  });
+  await wf.condition(() => total > 0);
+  return total;
+}

features/update/activities/README.md

@@ -1,11 +1,8 @@
 # Run activities from within a workflow update
 
-Workflows can run activities from within an update handler
+Workflows can run activities from within an update handler.
 
 # Detailed spec
 
-Workflow update handlers are like workflow code in that they can run for
-indefinitely long periods but must do so by invoking and waiting on activites.
-This test invokes a number of activities within the update and blocks on them,
-returning from the update when they have all completed.
-
+Workflow update handlers are like workflow code in that they can invoke and wait on activities.
+This test invokes a number of activities within the update and blocks on them, returning from the update when they have all completed.

features/update/async_accepted/README.md

@@ -5,7 +5,7 @@ Updates can be invoked asynchronously by waiting on the ACCEPTED state.
 # Detailed spec
 
 It will be possible to invoke an update and indicate that the calling RPC client
-wants the RPC call to block on on completion of the update but rather on the the
+wants the RPC call to block not on completion of the update but rather on the the
 update passing validation on the workflow - this is called the "Accepted" state.
 The update continues to execute to completion despite there being no caller
 waiting on its outcome.
@@ -15,4 +15,3 @@ workflow ID, run ID, and update ID) can create a handle to that update and await
 the outcome of the update call. Outcomes returned from these asynchronous
 updates are the same as those that would have been returned inline had the
 update been invoked synchronously.
-

features/update/client_interceptor/README.md

@@ -0,0 +1,8 @@
+# Update Calls Can Be Intercepted
+
+Client Interceptors can intercept and modify update requests
+
+# Detailed spec
+
+A client interceptor can be configured that modifies the arguments sent by a client to an Update handler.
+The modification is reflected in the Update response.

features/update/intercept/feature.java → features/update/client_interceptor/feature.java

@@ -1,4 +1,4 @@
-package update.intercept;
+package update.client_interceptor;
 
 import io.temporal.client.WorkflowClientOptions;
 import io.temporal.common.interceptors.WorkflowClientCallsInterceptor;

features/update/task_failure/README.md

@@ -8,4 +8,4 @@ the caller side.
 The error received by the caller will be through the handle.Get call and will
 contain the string contents of the panic/exception message. Panics/Exceptions out of validation
 handlers are equivalent to rejections from a durability perspective while panics/exceptions
-from the main execution function are the equivalent of panicing/throwing in a workflow task.
+from the main execution function are the equivalent of panicking/throwing in a workflow task.

harness/java/io/temporal/sdkfeatures/PreparedFeature.java

@@ -32,7 +32,7 @@ public class PreparedFeature {
           update.activities.feature.Impl.class,
           update.async_accepted.feature.Impl.class,
           update.deduplication.feature.Impl.class,
-          update.intercept.feature.Impl.class,
+          update.client_interceptor.feature.Impl.class,
           update.non_durable_reject.feature.Impl.class,
           update.task_failure.feature.Impl.class,
           update.worker_restart.feature.Impl.class,