add RESET_REQUESTED state to standalone activity by spkane31 · Pull Request #10364 · temporalio/temporal

spkane31 · 2026-05-22T18:54:36Z

What changed?

Replace the flagged base RESET state with a RESET_REQUESTED state. This takes fuller advantage of the CHASM state transition functionality.

Why?

Reduces the amount of special casing code and replaces this with an additional state (RESET_REQUESTED) and state transitions to handle the case where a STARTED activity is reset and has to be delivered on the next heartbeat or when an activity completes the attempt.

How did you test it?

Potential risks

NA, unreleased code.

dandavison

Did a pass. Looks good; a few things suggested in comments.

dandavison · 2026-05-29T00:26:59Z

 	func(a *Activity, ctx chasm.MutableContext, event completeEvent) error {
 		return a.StoreOrSelf(ctx).RecordCompleted(ctx, func(ctx chasm.MutableContext) error {
-			a.ActivityReset = false
+			a.PauseState = nil


We shouldn't clear PauseState because no logic should be expressed in terms of PauseState and it's cleaner just to let it be, rather than have the code imply that something would go wrong if it's not cleared in all the right places.

Same comment applies to all the places below where PauseState is cleared.

This will make it like CancelState and TerminateState. As I mentioned in other comments, I'd be open to calling it LastPauseState to make it clear that this one might be non-current unlike CancelState and TerminateState which I believe are always current (but lmk if that's wrong).

dandavison · 2026-05-29T00:27:06Z

 		CancelRequested: a.Status == activitypb.ACTIVITY_EXECUTION_STATUS_CANCEL_REQUESTED,
-		ActivityPaused:  a.Status == activitypb.ACTIVITY_EXECUTION_STATUS_PAUSE_REQUESTED,
-		ActivityReset:   a.ActivityReset,
+		ActivityPaused:  (a.PauseState != nil || a.Status == activitypb.ACTIVITY_EXECUTION_STATUS_PAUSE_REQUESTED) && a.Status != activitypb.ACTIVITY_EXECUTION_STATUS_CANCEL_REQUESTED,


With the change to PauseRequested we should not be using PauseState as a flag any longer. And IMO we shouldn't ever clear it: just let it be set without clearing, like CancelState and TerminateState. We could call it LastPauseState to emphasize that it isn't necessarily current -- does that rename appeal to you?

I think we'll need to store ResetKeepPaused on the activity state.

So this line should look like

ActivityPaused: a.Status == PAUSE_REQUESTED || (a.Status == RESET_REQUESTED && a.ResetKeepPaused)

dandavison · 2026-05-29T00:27:14Z

+		if !keepPaused {
+			// Clear PauseState now so the deferred reset can dispatch on retry without being
+			// blocked by the validator (which drops dispatch tasks when PauseState != nil).
+			a.PauseState = nil


The task validators no longer gate on PauseState so this is not needed.

dandavison · 2026-05-29T15:40:28Z

 		return a.StoreOrSelf(ctx).RecordCompleted(ctx, func(ctx chasm.MutableContext) error {
 			req := event.req.GetFailedRequest()
-			a.ActivityReset = false
+			a.PauseState = nil


No need to clear PauseState (see comment above)

dandavison · 2026-05-29T15:41:21Z

 				RequestId: event.request.RequestID,
 			}
-			a.ActivityReset = false
+			a.PauseState = nil


No need to clear PauseState (see comment above)

dandavison · 2026-05-29T15:41:26Z

 				},
 			}
-			a.ActivityReset = false
+			a.PauseState = nil


No need to clear PauseState (see comment above)

dandavison · 2026-05-29T15:41:31Z

 			}

-			a.ActivityReset = false
+			a.PauseState = nil


No need to clear PauseState (see comment above)

dandavison · 2026-05-29T18:54:58Z

+		// keepPaused on a paused (PAUSE_REQUESTED) activity preserves the pause: when the worker
+		// yields the activity lands back in PAUSED rather than SCHEDULED. Recorded as an explicit
+		// flag so no logic has to gate on the descriptive LastPauseState field.
+		a.ResetKeepPaused = keepPaused && a.Status == activitypb.ACTIVITY_EXECUTION_STATUS_PAUSE_REQUESTED


The second part of the comment will be hard for a future reader to understand.

Suggested change

// keepPaused on a paused (PAUSE_REQUESTED) activity preserves the pause: when the worker

// yields the activity lands back in PAUSED rather than SCHEDULED. Recorded as an explicit

// flag so no logic has to gate on the descriptive LastPauseState field.

a.ResetKeepPaused = keepPaused && a.Status == activitypb.ACTIVITY_EXECUTION_STATUS_PAUSE_REQUESTED

// keepPaused on a paused (PAUSE_REQUESTED) activity preserves the pause: when the worker

// yields the activity lands back in PAUSED rather than SCHEDULED.

dandavison · 2026-05-29T19:49:07Z

+// keepPaused=true while the activity was in PAUSE_REQUESTED). The failed attempt is recorded, the
+// attempt count is reset to 1, and no dispatch task is emitted — the activity stays paused until
+// an explicit unpause.
+var TransitionResetAttemptFailedToPaused = chasm.NewTransition(


We might want to look again over our transition names to see if we're happy with how consistent they are (I used While but after some back and forth, and I know yours have to distinguish between the two destinations). But we don't have to do that now since tit has no impact on persisted data or public exposure -- can fiddle with them at any time in the future.

dandavison

LGTM!

## What changed? Replace the flagged base `RESET` state with a `RESET_REQUESTED` state. This takes fuller advantage of the CHASM state transition functionality. ## Why? Reduces the amount of special casing code and replaces this with an additional state (`RESET_REQUESTED`) and state transitions to handle the case where a `STARTED` activity is reset and has to be delivered on the next heartbeat or when an activity completes the attempt. ## How did you test it? - [ ] built - [ ] run locally and tested manually - [X] covered by existing tests - [ ] added new unit test(s) - [X] added new functional test(s) ## Potential risks NA, unreleased code.

Implements Pause, Unpause, Reset, and UpdateActivityExecutionOptions RPCs for standalone CHASM activities. Adds matching frontend and history service handlers in chasm/lib/activity that dispatch to either the workflow-activity path or the standalone-activity path based on the presence of a workflow ID. Also adds PAUSE_REQUESTED and RESET_REQUESTED state machine states for standalone activities, the original_options snapshot for restore-on-reset semantics, the activity-options merge helpers (common/activityoptions), and the supporting proto schema changes (start_request_id, sdk_name, sdk_version, etc.). Squash of the 29 commits previously on this branch. Original PRs: #9693 RPC boilerplate and code generation #9850 Implement UpdateActivityExecutionOptions #9851 Implement Pause/UnpauseActivityExecution for SAA #9852 Implement ResetActivityExecution for SAA #10001 Pause returns FailedPrecondition when already paused #10025 Validator function fixes #10265 Replace PauseState flag with PAUSE_REQUESTED state #10364 Add RESET_REQUESTED state to standalone activity

spkane31 requested review from a team as code owners May 22, 2026 18:54

spkane31 requested a review from dandavison May 22, 2026 18:54

spkane31 added 4 commits May 28, 2026 09:23

add RESET_REQUESTED state to standalone activity

054caa3

breaking buf

c5f7cd3

wrong buf breaking file

91a4a80

fixing bad merge

5cacf1e

spkane31 force-pushed the spk/reset-requested branch from 1595173 to 5cacf1e Compare May 28, 2026 15:56

dandavison reviewed May 29, 2026

View reviewed changes

remove reliance on PauseState, rename to LastPauseState and never clear

2b77d61

spkane31 requested a review from dandavison May 29, 2026 18:16

dandavison reviewed May 29, 2026

View reviewed changes

single comment

830dfcb

dandavison reviewed May 29, 2026

View reviewed changes

dandavison approved these changes May 29, 2026

View reviewed changes

spkane31 merged commit 0ddb873 into feature/activity-operator-cmds May 29, 2026
46 checks passed

spkane31 deleted the spk/reset-requested branch May 29, 2026 20:15

Uh oh!

Conversation

spkane31 commented May 22, 2026

What changed?

Why?

How did you test it?

Potential risks

Uh oh!

dandavison 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!

Choose a reason for hiding this comment

Uh oh!

dandavison left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants