Implement UpdateActivityExecutionOptions by spkane31 · Pull Request #9850 · temporalio/temporal

spkane31 · 2026-04-07T21:49:40Z

What changed?

Implements the UpdateActivityExecutionOptions RPC for standalone activities. The workflow-activity path is already supported via the existing UpdateActivityOptions history service API this PR only wires up the standalone path end-to-end.

Core changes:

chasm/lib/activity/activity.go — Adds UpdateActivityExecutionOptions method on Activity:
- Validates mutual exclusion of update_mask / restore_original
- restore_original: bulk-assigns all fields from the original_options snapshot stored at schedule time
- Field-mask path: applies only the specified fields via mergeActivityOptions
- Stamp invalidation: bumps attempt.Stamp to cancel in-flight ActivityDispatchTask and timeout tasks, then re-queues a new dispatch and schedule-to-start timeout
- Retry interval recalculation: after a retry-policy update, recomputes attempt.CurrentRetryInterval so the re-dispatch fires at the new (possibly shorter) interval rather than the stale one
- Schedule-to-close update: adds a new ScheduleToCloseTimeoutTask at the updated deadline so a shortened timeout fires immediately
- Adds original_options to ActivityState proto and populates it in NewStandaloneActivity
chasm/lib/activity/handler.go — Routes the standalone path to chasm.UpdateComponent to (*Activity).UpdateActivityExecutionOptions
chasm/lib/activity/frontend.go — Adds input validation (validateUpdateActivityExecutionOptionsRequest: activity ID required/length, identity length, run ID UUID), and gates the standalone path behind the Enabled config flag while always permitting the workflow path

Why?

UpdateActivityExecutionOptions is the new unified RPC for updating activity options for both standalone activities and workflow-embedded activities.

How did you test it?

Potential risks

Minimal, this is into a feature branch

fretz12 · 2026-04-08T23:43:58Z

+	// Discard stale tasks created before a schedule-to-close extension.
+	// When the deadline is extended, a new task is added at the updated deadline; any earlier
+	// task (from the old shorter deadline) must not time out the activity prematurely.
+	if timeout := activity.GetScheduleToCloseTimeout().AsDuration(); timeout > 0 {


If a user updates the options such that scheduleToClose is 0 (disabled), this validation would cause a spurious fire.
We should add a check.

timeout := activity.GetScheduleToCloseTimeout().AsDuration() if timeout <= 0 { return false, nil }

Also, I'm wondering if it's more robust to have a dedicated stamp (like we do for attempt) for scheduleToClose. A bit more extra storage, but avoids any time comparisons for validations as it can be fragile. @bergundy @dandavison lmk your thoughts

Yeah, just put a stamp on this instead IMHO. Just make sure that if there's no stamp on the task it's not used for validation.

Let's remember to update the comment here: https://github.com/temporalio/temporal/blob/dan/activity-operator-update-options/chasm/lib/activity/proto/v1/activity_state.proto#L143-L148

…if non terminal, re-validate options, general code hygiene

dandavison · 2026-04-09T16:30:28Z

+	// Discard stale tasks created before a schedule-to-close extension.
+	// When the deadline is extended, a new task is added at the updated deadline; any earlier
+	// task (from the old shorter deadline) must not time out the activity prematurely.
+	if timeout := activity.GetScheduleToCloseTimeout().AsDuration(); timeout > 0 {


Let's remember to update the comment here: https://github.com/temporalio/temporal/blob/dan/activity-operator-update-options/chasm/lib/activity/proto/v1/activity_state.proto#L143-L148

dandavison · 2026-04-09T21:24:27Z

+				chasm.TaskAttributes{ScheduledTime: deadline},
+				&activitypb.StartToCloseTimeoutTask{Stamp: attempt.GetStamp()},
+			)
+		}


We need to regenerate the heartbeat task also to cover the case where the pending heartbeat task was invalidated by the stamp bump. It looks like the heartbeating test works around that to make it pass.

Dispatched the heartbeat task using the same logic in TransitionStarted and changed the test to remove the heartbeating to force the task generation

dandavison · 2026-04-09T21:28:09Z

+			)
+		}
+	}
+


Maybe worth leaving a comment here for ourselves that we need to handle the StartDelay timer also.

dandavison · 2026-04-09T21:29:41Z

+		require.NoError(t, err)
+
+		// Heartbeat once — this creates a new HeartbeatTimeoutTask with the updated 2s timeout
+		// and the new stamp. Without this heartbeat the timer would not be armed.


I don't think we should be doing this -- it's papering over the lack of heartbeat task regeneration in the implementation.

dandavison · 2026-04-10T02:42:56Z

+
+	attempt.Stamp++
+
+	if a.GetStatus() == activitypb.ACTIVITY_EXECUTION_STATUS_STARTED {


We need to also consider CANCEL_REQUESTED -- we don't want to miss a heartbeat timeout while in CANCEL_REQUESTED. It look like there's a pre-existing bug in that the start-to-close task validator rejects the task if it is in CANCEL_REQUESTED; I've opened #9901 for that. So I believe the condition here should be STARTED || CANCEL_REQUESTED.

Added your changes into the branch

…overage

fretz12 · 2026-04-10T20:53:05Z

 	activity := &Activity{
-		ActivityState: &activitypb.ActivityState{
-			ActivityType:           request.ActivityType,
+		ActivityState: common.CloneProto(&activitypb.ActivityState{


maybe a brief comment on why we're cloning

fretz12 · 2026-04-10T21:10:05Z

+// for workflow-embedded activities; complexity is inherent to the per-field update pattern.
+//
+//nolint:revive // cyclomatic: field-mask application mirrors existing updateactivityoptions logic
+func (a *Activity) mergeActivityOptions(


Can we refactor the core logic here with that in the merge method in service/history/api/updateactivityoptions/api.go? It's largely a repeat and good to have all in one place.

bergundy · 2026-04-10T22:12:31Z

 	return nil
 }

+func validateUpdateActivityExecutionOptionsRequest(


We should be validating the following:

TaskQueue: Use standard task queue validation, this is a security risk that can cause an activity to be executed on the per-namespace-worker task queue ScheduleToCloseTimeout: validate+normalize with standard timeout validator ScheduleToStartTimeout: validate+normalize with standard timeout validator StartToCloseTimeout: validate+normalize with standard timeout validator HeartbeatTimeout: validate+normalize with standard timeout validator Priority: already validated RetryPolicy: I am pretty sure there's a validator and maybe normalizer for this.

dandavison · 2026-04-10T21:06:39Z

+    // An incremental version number used to validate ScheduleToCloseTimeoutTask tasks.
+    // Incremented each time a new ScheduleToCloseTimeoutTask is scheduled (at activity creation
+    // and on each options update that re-schedules the task). Unlike attempt.stamp, this counter
+    // is NOT reset on retries, because schedule-to-close spans the full activity lifetime.


Suggested change

// is NOT reset on retries, because schedule-to-close spans the full activity lifetime.

// is NOT incremented on retries, because schedule-to-close spans the full activity lifetime.

dandavison · 2026-04-10T21:07:57Z

 }

 message ScheduleToCloseTimeoutTask {
+    // The current schedule-to-close stamp for this activity. Used for task validation.


Suggested change

// The current schedule-to-close stamp for this activity. Used for task validation.

// The schedule-to-close stamp for this task. Used for task validation.

dandavison · 2026-04-10T21:09:30Z

+			// The next heartbeat time is the max of (the last heartbeats recorded time and
+			// the current attempts started time) plus the heartbeat timeout
+			lastHb, _ := a.LastHeartbeat.TryGet(ctx)
+			lastHBTime := util.MaxTime(


nit: inconsistent lastHb vs lastHB

dandavison · 2026-04-13T13:00:07Z

+			mergeInto.RetryPolicy = &commonpb.RetryPolicy{}
+		}
+		mergeInto.RetryPolicy.MaximumAttempts = mergeFrom.GetRetryPolicy().GetMaximumAttempts()
+	}


Not blocking this PR but looking at this feature and the existing UpdateWorkflowOptions feature, it would be easy to add an option and forget to handle it in the merge/update/value-clearing logic. It would be good to have tests that uses protobuf reflection to verify that all possible paths are either handled by the update APIs or intentionally not offered for update/clearing.

Added a test for this, great idea!

Implements the `UpdateActivityExecutionOptions` RPC for standalone activities. The workflow-activity path is already supported via the existing UpdateActivityOptions history service API this PR only wires up the standalone path end-to-end. Core changes: - `chasm/lib/activity/activity.go` — Adds UpdateActivityExecutionOptions method on Activity: - Validates mutual exclusion of `update_mask` / `restore_original` - `restore_original`: bulk-assigns all fields from the `original_options` snapshot stored at schedule time - Field-mask path: applies only the specified fields via `mergeActivityOptions` - Stamp invalidation: bumps `attempt.Stamp` to cancel in-flight `ActivityDispatchTask` and timeout tasks, then re-queues a new dispatch and schedule-to-start timeout - Retry interval recalculation: after a retry-policy update, recomputes `attempt.CurrentRetryInterval` so the re-dispatch fires at the new (possibly shorter) interval rather than the stale one - Schedule-to-close update: adds a new `ScheduleToCloseTimeoutTask` at the updated deadline so a shortened timeout fires immediately - Adds `original_options` to `ActivityState` proto and populates it in `NewStandaloneActivity` - chasm/lib/activity/handler.go — Routes the standalone path to `chasm.UpdateComponent` to (*Activity).UpdateActivityExecutionOptions - chasm/lib/activity/frontend.go — Adds input validation (`validateUpdateActivityExecutionOptionsRequest`: activity ID required/length, identity length, run ID UUID), and gates the standalone path behind the Enabled config flag while always permitting the workflow path UpdateActivityExecutionOptions is the new unified RPC for updating activity options for both standalone activities and workflow-embedded activities. - [ ] built - [ ] run locally and tested manually - [ ] covered by existing tests - [ ] added new unit test(s) - [X] added new functional test(s) Minimal, this is into a feature branch

spkane31 requested review from a team as code owners April 7, 2026 21:49

spkane31 added 2 commits April 7, 2026 16:05

first attempt at implementing update activity execution options

acd2a25

fix broken tests

6e743f6

spkane31 force-pushed the spk/activity-operator-update-options branch from adcb1b0 to 6e743f6 Compare April 7, 2026 22:05

spkane31 changed the title ~~Spk/activity operator update options~~ Implement UpdateActivityExecutionOptions Apr 7, 2026

spkane31 added 4 commits April 7, 2026 16:39

linter and more tests for parity

110c001

formatting

e627b7e

fix update tests and discard stale tasks before sched2close changes

fb22f71

self review

4178c31

spkane31 requested review from dandavison and fretz12 April 8, 2026 17:53

fretz12 reviewed Apr 9, 2026

View reviewed changes

spkane31 added 2 commits April 9, 2026 11:54

addressing freds comments, tests while started, s2c fix, update only …

9dd9cae

…if non terminal, re-validate options, general code hygiene

linter and a test fix

3797d74

spkane31 requested review from bergundy and fretz12 April 9, 2026 18:58

dandavison reviewed Apr 9, 2026

View reviewed changes

addressing dans comments about heartbeating

58bb8a0

spkane31 requested a review from dandavison April 9, 2026 22:37

fretz12 reviewed Apr 9, 2026

View reviewed changes

dandavison reviewed Apr 10, 2026

View reviewed changes

spkane31 added 3 commits April 10, 2026 10:11

renaming, copy proto defns, started || cancel req, adding unit test c…

dcacaf4

…overage

linter catches

7608f49

porting in Dans changes

c4c7d8f

spkane31 requested review from dandavison and fretz12 April 10, 2026 17:29

fretz12 approved these changes Apr 10, 2026

View reviewed changes

put merge actions in its own file, add comment about cloning

b5107f8

bergundy reviewed Apr 10, 2026

View reviewed changes

validators from roeys comments

aa77a8a

dandavison reviewed Apr 13, 2026

View reviewed changes

spkane31 added 6 commits April 13, 2026 08:50

linters

b08a277

dans comments

7a56775

float-compare

bf9afea

add a reflection test to validate all fields can be updated

36ae549

consistency

a7a82de

regen

56d4995

spkane31 merged commit 0cbb52d into feature/activity-operator-cmds Apr 13, 2026
41 of 45 checks passed

spkane31 deleted the spk/activity-operator-update-options branch April 13, 2026 21:23


		attempt.Stamp++

		if a.GetStatus() == activitypb.ACTIVITY_EXECUTION_STATUS_STARTED {

	// is NOT reset on retries, because schedule-to-close spans the full activity lifetime.
	// is NOT incremented on retries, because schedule-to-close spans the full activity lifetime.

	// The current schedule-to-close stamp for this activity. Used for task validation.
	// The schedule-to-close stamp for this task. Used for task validation.

Conversation

spkane31 commented Apr 7, 2026

What changed?

Why?

How did you test it?

Potential risks

Uh oh!

Uh oh!

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!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dandavison Apr 9, 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!

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!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

dandavison Apr 10, 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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bergundy Apr 10, 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!

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!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

dandavison Apr 9, 2026 •

edited

Loading

dandavison Apr 10, 2026 •

edited

Loading

bergundy Apr 10, 2026 •

edited

Loading