RPC boiler plate and code generation by spkane31 · Pull Request #9693 · temporalio/temporal

spkane31 · 2026-03-26T19:46:27Z

What changed?

Add four new RPC methods to historyservice(PauseActivityExecution,UnpauseActivityExecution,ResetActivityExecution,UpdateACtivityExecutionOptions)
Add new historyservice request/response messages wrapping api repos requests
Generated code

Why?

First step towards supporting the four activity operator commands on both workflow activities and standalone CHASM activities.

The overall aim of this branch is to support operator API commands (Pause, Unpause, Reset, UpdateOptions) for both Standalone Activities (SAA) and Workflow Activities (WA). These will share the same new external workflowservice RPC entrypoints and will be distinguished by the presence of a workflow ID. Pause, Unpause, UpdateOptions, and Reset already exist for WA with an experimental and soon-to-be deprecated public API. The API handlers added in this PR route to the current experimental implementation. We define Frontend and History service RPC handlers in chasm/lib/activity. Requests for both SAA and WA are routed from Frontend to History using these handlers. The handler in the history service (part of the CHASM ActivityService which is hosted by History service) then inspects the workflow ID and activity ID and dispatches according to whether the request is for an SAA vs WA.

How did you test it?

Potential risks

No runtime behavior changes.

spkane31

These are all the places I actually changed, the rest are code gen

spkane31 · 2026-03-26T22:53:02Z

 }
+
+
+message PauseActivityExecutionRequest {


Duplicating existing requests

spkane31 · 2026-03-26T22:54:30Z

        option (temporal.server.api.common.v1.api_category).category = API_CATEGORY_STANDARD;
    }
+
+    rpc PauseActivityExecution(PauseActivityExecutionRequest) returns (PauseActivityExecutionResponse) {


Adding new requests

spkane31 · 2026-03-26T22:55:24Z

    temporal.api.activity.v1.ActivityOptions activity_options = 1;
 }

+// (-- api-linter: core::0134::request-mask-required=disabled


history service APIs routed on resource ID for all four operations

I think we can have just one handler here in the activity lib that will handle both workflow and standalone activities.

This comment was not addressed. You can call the old UpdateActivityOptions API that is already implemented from the activity handler.

spkane31 · 2026-03-26T22:55:42Z

        option (temporal.server.api.common.v1.api_category).category = API_CATEGORY_STANDARD;
    }

+    // UpdateActivityExecutionOptions is called by the client to update the options of an activity


historyservice RPCs

spkane31 · 2026-03-26T22:56:10Z

 	return &workflowservice.UnpauseWorkflowExecutionResponse{}, nil
 }
+
+func (wh *WorkflowHandler) PauseActivityExecution(


Stubs that will be implemented later

spkane31 · 2026-03-26T22:56:24Z

 		ResetActivity(ctx context.Context, request *historyservice.ResetActivityRequest) (*historyservice.ResetActivityResponse, error)
 		PauseWorkflowExecution(ctx context.Context, request *historyservice.PauseWorkflowExecutionRequest) (*historyservice.PauseWorkflowExecutionResponse, error)
 		UnpauseWorkflowExecution(ctx context.Context, request *historyservice.UnpauseWorkflowExecutionRequest) (*historyservice.UnpauseWorkflowExecutionResponse, error)
+		UpdateActivityExecutionOptions(ctx context.Context, request *historyservice.UpdateActivityExecutionOptionsRequest) (*historyservice.UpdateActivityExecutionOptionsResponse, error)


Adding for code generation and mock generation

bergundy

I'm on the fence on whether workflow and standalone should have different handlers in the history service. In my mind they have a single handler in chasm/lib/activity/handler.go and that dispatches to the history handler. When we port workflow activities, the implementation of that handler would be very simple but for now you can inject a history handler into the activity handler and call the old methods from there.

You can see in my signal-with-start from workflow how to get a history handler injected.

bergundy · 2026-03-27T22:42:22Z

    }
+
+    rpc PauseActivityExecution(PauseActivityExecutionRequest) returns (PauseActivityExecutionResponse) {
+        option (temporal.server.api.routing.v1.routing).business_id = "frontend_request.activity_id";


What about when workflow_id is the business_id?
We can consider making the business_id a repeated field in the annotation and fallback from workflow_id to activity_id. See the protoc plugin that generates the code for how to achieve that.

I don't think you can use resource ID here.

Changing business_id to a repeated field is going to fire our breaking change checker, is this a breaking change we are OK with?

I added a business_id_fallback which is not a breaking change, but if we wanted to add a repeated I can make that change.

Changed back to a repeated business_id, does this need to be merged into main to prevent issues later on?

bergundy · 2026-03-27T22:44:19Z

    temporal.api.activity.v1.ActivityOptions activity_options = 1;
 }

+// (-- api-linter: core::0134::request-mask-required=disabled


I think we can have just one handler here in the activity lib that will handle both workflow and standalone activities.

bergundy · 2026-03-27T22:45:43Z

+// (-- api-linter: core::0134::request-mask-required=disabled
+// (-- api-linter: core::0134::request-resource-required=disabled
+message UpdateActivityExecutionOptionsRequest {
+    option (routing).workflow_id = "frontend_request.resource_id";


Does this work? I think the resource ID has a prefix in these cases.

Changed to workflow ID

bergundy · 2026-03-27T22:58:49Z

 	return &workflowservice.UnpauseWorkflowExecutionResponse{}, nil
 }
+
+func (wh *WorkflowHandler) PauseActivityExecution(


Put this in chasm/lib/activity/frontend.go as we have done for other activity APIs please.

dandavison

I took a stab at writing up my understanding of the PR. (Something like this could be useful as PR description if accurate).

(Just submitting one comment for now; got pulled away.)

--

The overall aim of this PR is to move towards supporting operator API commands (Pause, Unpause, Reset, UpdateOptions) for both Standalone Activities (SAA) and Workflow Activities (WA). These will share the same new external workflowservice RPC entrypoints and will be distinguished according to whether or not the request has a workflow ID.

In fact, for Pause, Unpause, and Reset there is already a WA implementation with an experimental and deprecated public API. The API handlers added in this PR route to the current experimental implementation.

The end result is the following: we define Frontend and History service RPC handlers in chasm/lib/activity. Requests for both SAA and WA are routed from Frontend to History using these handlers. The handler in the history service (part of the CHASM ActivityService which is hosted by History service) then inspects the workflow ID and activity ID and dispatches according to whether the request is for an SAA vs WA. Apart from UpdateOptions, the WA dipatch is to an existing implementation.

dandavison · 2026-03-31T19:59:17Z

+) (*workflowservice.PauseActivityExecutionResponse, error) {
+	if !h.config.Enabled(req.GetNamespace()) {
+		return nil, ErrStandaloneActivityDisabled
+	}


We're on the path for both SAA and WA here, so this means that WA Pause will fail if SAA is disabled. I think that's a bug.

Fixed for all four

spkane31 · 2026-03-31T21:59:39Z

@dandavison I added your comment into the PR description and corrected some parts, for example updateoptions already exists in workflow activities

dandavison · 2026-04-01T20:07:40Z

+				Reason:   frontendReq.GetReason(),
+				Identity: frontendReq.GetIdentity(),
+			},
+		})


How about in this PR, to prove some of the changes here are correct, you add new variants for the existing functional tests for all 4 operations that test them via the new API? AIUI that should work.

I added a simple test for each path for success in the happy path (workflow) and failure on the SAA path. With each implementation it will require repeating the existing activity api suites for three scenarios:

the existing activity operator API suite

the new operator API targeted at workflow activity

new operator API targeted at SAA

I omitted these to keep this PR easier to review for now but that will come in future PRs.

dandavison · 2026-04-01T20:17:55Z

@@ -457,6 +461,100 @@ func activityOptionsFromStartRequest(req *workflowservice.StartActivityExecution
 }

 // applyActivityOptionsToStartRequest copies normalized values from ActivityOptions


This comment got left in the wrong place

bergundy · 2026-04-02T22:33:51Z

Add TODOs to validate all of the requests?

bergundy · 2026-04-02T22:35:27Z

 }

-func newHandler(config *Config, metricsHandler metrics.Handler, logger log.Logger, namespaceRegistry namespace.Registry) *handler {
+func newHandler(config *Config, historyClient resource.HistoryClient, metricsHandler metrics.Handler, logger log.Logger, namespaceRegistry namespace.Registry) *handler {


You don't need a history client here, just get the grpc handler here and invoke it directly, skipping the network overhead. I did that in the signal-with-start from workflow WIP branch.

bergundy · 2026-04-02T22:39:53Z

    temporal.api.activity.v1.ActivityOptions activity_options = 1;
 }

+// (-- api-linter: core::0134::request-mask-required=disabled


This comment was not addressed. You can call the old UpdateActivityOptions API that is already implemented from the activity handler.

bergundy · 2026-04-02T22:40:30Z

As I've mentioned before, no changes are needed in this service.

bergundy · 2026-04-02T22:41:05Z

    # example: - temporal/server/api/.../message.proto
    - temporal/server/api/persistence/v1/chasm.proto
    - temporal/server/api/token/v1/message.proto
+    # TODO: Remove once this is stable. business_id was intentionally changed from


All of the exceptions here should be removed ASAP.

This will have to stay until this PR is merged into main, then can be removed in a subsequent PR unless there's another method that I am missing

Addressed the rest of them in #9806

bergundy · 2026-04-02T22:42:48Z

+
+// makeWorkflowFuncForNewAPITests returns a workflow function that runs a single activity with a
+// long schedule-to-close timeout and the given retry policy.
+func (s *standaloneActivityTestSuite) makeWorkflowFuncForNewAPITests(activityFn ActivityFunctions, retryPolicy *temporal.RetryPolicy) WorkflowFunction {


Don't put workflow tests in a file that is supposed to test standalone activities please. Also, I would wait with these tests until there's something implemented.

@dandavison asked for them to validate the implementation.

I do think it makes sense to add tests for the workflow activity portion, since that should be fully functioning. Instead of adding a new file tests/activity_api_execution_test.go is is possible to achieve that coverage by parameterizing the existing tests in activity_api_pause_test.go? I.e. confirming that all the existing test coverage for PauseActivityRequest still holds when using PauseActivityExecutionRequest.

I'm fine with adding stubbed tests for the new Standalone Activity functionality. It's healthy to confirm that the wiring in this PR works even though the full test can come later.

I was able to parameterize the existing XXXActivity and XXXActivityExecution operators in the tests, looks cleaner and removes an extra test file

…rvice, separate wf and saa tests

fretz12 · 2026-04-06T21:49:20Z

+
+		s.WaitForChannel(ctx, activityStartedCh)
+
+		_, err = s.FrontendClient().PauseActivity(ctx, &workflowservice.PauseActivityRequest{


Should this call PauseActivityExecution instead?

dandavison · 2026-04-07T21:53:00Z

+		return nil, ErrStandaloneActivityDisabled
+	}
+
+	// TODO: validate request fields (e.g. namespace, identity length)


Let's add TODOs to validate that either workflowID or activityID is set before allowing it to be routed to a history shard using "".

* Add four new RPC methods to `historyservice`(PauseActivityExecution,UnpauseActivityExecution,ResetActivityExecution,UpdateACtivityExecutionOptions) * Add new historyservice request/response messages wrapping api repos requests * Generated code First step towards supporting the four activity operator commands on both workflow activities and standalone CHASM activities. The overall aim of this branch is to support operator API commands (Pause, Unpause, Reset, UpdateOptions) for both Standalone Activities (SAA) and Workflow Activities (WA). These will share the same new external workflowservice RPC entrypoints and will be distinguished by the presence of a workflow ID. Pause, Unpause, UpdateOptions, and Reset already exist for WA with an experimental and soon-to-be deprecated public API. The API handlers added in this PR route to the current experimental implementation. We define Frontend and History service RPC handlers in chasm/lib/activity. Requests for both SAA and WA are routed from Frontend to History using these handlers. The handler in the history service (part of the CHASM ActivityService which is hosted by History service) then inspects the workflow ID and activity ID and dispatches according to whether the request is for an SAA vs WA. - [ ] built - [ ] run locally and tested manually - [ ] covered by existing tests - [ ] added new unit test(s) - [ ] added new functional test(s) No runtime behavior changes.

RPC boiler plate and code generation

bb227c4

spkane31 requested review from a team as code owners March 26, 2026 19:46

add stub methods to WorkflowHandler

e817810

spkane31 requested review from bergundy and dandavison March 26, 2026 20:05

Add chasm/lib/activity proto updates

2945608

spkane31 requested a review from a team as a code owner March 26, 2026 20:33

return update options response

e53aa9b

spkane31 removed request for bergundy and dandavison March 26, 2026 21:12

spkane31 added 2 commits March 26, 2026 15:18

add to the history engine interface

476e93f

fixing unit test changes

c3eb1f5

spkane31 requested review from bergundy and dandavison March 26, 2026 22:52

spkane31 commented Mar 26, 2026

View reviewed changes

bergundy reviewed Mar 27, 2026

View reviewed changes

spkane31 added 2 commits March 30, 2026 10:51

single handler, fixing routing IDs

ba733e7

use a fallback instead of repeated

e33dbc3

spkane31 requested a review from bergundy March 30, 2026 18:03

dandavison reviewed Mar 31, 2026

View reviewed changes

fix routing error

ab3d237

spkane31 requested a review from dandavison March 31, 2026 21:59

dandavison reviewed Apr 1, 2026

View reviewed changes

add tests for both wf and saa paths, remove single comment

87a6036

spkane31 requested a review from dandavison April 1, 2026 21:32

spkane31 added 2 commits April 2, 2026 12:18

use the repeated business_id

8d131a5

breaking change warning

3c13102

bergundy reviewed Apr 2, 2026

View reviewed changes

spkane31 added 2 commits April 3, 2026 09:36

change history client to history handler, remove changes to historyse…

4b2720e

…rvice, separate wf and saa tests

fix test

c464426

spkane31 requested review from bergundy and fretz12 April 6, 2026 18:53

fretz12 reviewed Apr 6, 2026

View reviewed changes

freds comments

a3297d6

spkane31 requested a review from fretz12 April 6, 2026 22:34

spkane31 added 2 commits April 7, 2026 09:54

formatting

58c26b0

change history nexusHandler to OnStart

375a070

fretz12 approved these changes Apr 7, 2026

View reviewed changes

parameterize activity operator commands

0af6d10

spkane31 merged commit 5560d42 into feature/activity-operator-cmds Apr 7, 2026
45 checks passed

spkane31 deleted the spk/rpc-boilerplate branch April 7, 2026 21:42

dandavison reviewed Apr 7, 2026

View reviewed changes

spkane31 mentioned this pull request Apr 29, 2026

Implement Pause/Unpause/Reset/UpdateOptions for standalone activities #10106

Open

5 tasks

		@@ -457,6 +461,100 @@ func activityOptionsFromStartRequest(req *workflowservice.StartActivityExecution
		}

		// applyActivityOptionsToStartRequest copies normalized values from ActivityOptions


		s.WaitForChannel(ctx, activityStartedCh)

		_, err = s.FrontendClient().PauseActivity(ctx, &workflowservice.PauseActivityRequest{

		}


		message PauseActivityExecutionRequest {

Conversation

spkane31 commented Mar 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What changed?

Why?

How did you test it?

Potential risks

Uh oh!

spkane31 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bergundy left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dandavison left a comment

Choose a reason for hiding this comment

Uh oh!

dandavison Mar 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

spkane31 commented Mar 31, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

spkane31 commented Mar 26, 2026 •

edited

Loading

dandavison Mar 31, 2026 •

edited

Loading

dandavison Apr 7, 2026 •

edited

Loading

dandavison Apr 7, 2026 •

edited

Loading