add functional tests to encode update activity task queue behavior#11002
Draft
spkane31 wants to merge 7 commits into
Draft
add functional tests to encode update activity task queue behavior#11002spkane31 wants to merge 7 commits into
spkane31 wants to merge 7 commits into
Conversation
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
## What changed? `start_delay` is now updatable via `UpdateActivityOptions` for standalone activities. The new value is anchored to the original `schedule_time`, so users can shorten it (including to 0, which dispatches immediately if the target is already past), extend it, or restore the original via `RestoreOriginal`. Updates once the activity has left its delay window (first dispatch passed, or no longer `SCHEDULED`) are rejected with `InvalidArgument`. The merge, validation, and namespace dynamic-config check from activity creation are reused, so create and update stay consistent. This also adds the shared infrastructure for the downstream PRs: - A persisted `first_attempt_started_time` on `ActivityState`, set once on the first `SCHEDULED → STARTED` and never updated on retries/resets. It is the canonical "has the first dispatch happened" discriminator. - A `respectStartDelay` helper that lifts a candidate dispatch time to `scheduleTime + start_delay` until first pickup, and no-ops afterward. It drives `ActivityDispatchTask` re-issuance so an unrelated update in the delay window no longer dispatches early, and gates the `RestoreOriginal` restore so it never shows a stale value post-dispatch. - Timer re-issuance split into `reissueRunningAttemptTimers` (StartToClose/Heartbeat) and `reissueScheduledDispatch` (Dispatch/ScheduleToStart). Also changes a pre-existing behavior where the update path anchored `ScheduleToClose` to `scheduleTime + timeout` instead of `firstDispatchTime + timeout`; it now uses the canonical `scheduleToCloseDeadline()`, matching `TransitionScheduled` and `hasEnoughTimeForRetry`. ## Why? Run-now (cancel-delay / kickstart) is table-stakes in the job queues SAA is replacing (BullMQ, Sidekiq, Cloud Tasks, Asynq) and a GA recommendation. Exposing `start_delay` through `UpdateActivityOptions` covers both run-now (set 0) and rescheduling with one primitive, using the same anchored-to-schedule-time semantics as creation. `start_delay` is a first-attempt parameter, so `first_attempt_started_time` keeps every re-scheduling path from re-applying or restoring it after dispatch, where it would only mislead. The `ScheduleToClose` change prevents an unrelated update during the delay window from shrinking the deadline (sometimes into the past) and timing the activity out before it dispatches. ## How did you test it? - [X] built - [X] run locally and tested manually - [X] covered by existing tests - [ ] added new unit test(s) - [X] added new functional test(s) --------- Co-authored-by: Dan Davison <dan.davison@temporal.io>
## What changed? Preserve standalone activity retry backoff when an activity is unpaused without `ResetAttempts`. The unpause path now only clears `CurrentRetryInterval` when attempts are explicitly reset. Updated standalone activity tests to verify that: - unpause does not make a retrying activity immediately pollable before its retry deadline - a later options update after unpause still preserves the pending retry backoff - `ResetAttempts` still clears retry backoff so the reset attempt can dispatch immediately ## Why? Unpause computes the correct retry-aware dispatch time, but clearing `CurrentRetryInterval` afterward meant any later dispatch reissue, such as `UpdateActivityExecutionOptions`, could no longer reconstruct the retry deadline and would dispatch the activity immediately. Keeping `CurrentRetryInterval` for normal unpause preserves retry timing across subsequent state updates, while still clearing it for `ResetAttempts`, where dropping the old retry delay is the intended behavior. ## How did you test it? - [X] built - [X] run locally and tested manually - [X] covered by existing tests - [ ] added new unit test(s) - [X] added new functional test(s)
## What changed? Fixed SAA unpause handling for activities in `RESET_REQUESTED` with `ResetKeepPaused=true`. Unpause now clears only the keep-paused intent while preserving the deferred reset. Added an e2e standalone activity test covering pause → reset with `keep_paused=true` → unpause before the worker reports back. ## Why? A deferred reset can carry two separate intents: apply the reset after the in-flight worker attempt reports back, and keep the reset attempt paused. Before this change, unpause did not clear the keep-paused intent while the reset was still deferred, so the activity could remain paused after the worker failed even though the user had already unpaused it. ## How did you test it? - [X] built - [X] run locally and tested manually - [ ] covered by existing tests - [ ] added new unit test(s) - [X] added new functional test(s)
## What changed? Updated SAA ScheduleToClose timer validation to require an exact stamp match. Legacy zero-stamp timers are now only accepted while the activity’s current ScheduleToClose stamp is also zero. ## Why? A stale pre-stamp ScheduleToClose timer could still time out an activity after update-options had extended the timeout and emitted a newer stamped timer. Matching stamps exactly prevents old timer tasks from remaining valid after the activity advances to a newer ScheduleToClose stamp. ## How did you test it? - [X] built - [X] run locally and tested manually - [ ] covered by existing tests - [ ] added new unit test(s) - [X] added new functional test(s)
fretz12
force-pushed
the
feature/activity-operator-cmds
branch
from
6d922e5 to
9ccc41b
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changed?
Additional testing to harden the operator API features.
Why?
More testing
How did you test it?
Potential risks
test only so far