Add support for updating start_delay via UpdateActivityOptions#10745
Open
fretz12 wants to merge 1 commit into
Open
Add support for updating start_delay via UpdateActivityOptions#10745fretz12 wants to merge 1 commit into
fretz12 wants to merge 1 commit into
Conversation
fretz12
force-pushed
the
fredtzeng/saa-start-delay-update
branch
from
e6ff106 to
a73e9e7
Compare
5 tasks
fretz12
force-pushed
the
fredtzeng/saa-start-delay-update
branch
from
a73e9e7 to
2bfa39e
Compare
5 tasks
fretz12
force-pushed
the
fredtzeng/saa-start-delay-update
branch
from
2bfa39e to
8b0c9ab
Compare
fretz12
force-pushed
the
fredtzeng/saa-start-delay-update
branch
from
8b0c9ab to
1dd4571
Compare
fretz12
commented
Jun 18, 2026
| // respectStartDelay lifts a candidate dispatch time up to scheduleTime + start_delay when the | ||
| // activity has not yet been picked up by a worker, so pre-dispatch re-scheduling (unpause, Reset+ | ||
| // RestoreOriginalOptions, options update) honors start_delay. No-op once dispatched. | ||
| func (a *Activity) respectStartDelay(scheduleTime time.Time) time.Time { |
Contributor
Author
There was a problem hiding this comment.
important helper reused in downstream PRs
fretz12
commented
Jun 18, 2026
| // reissueScheduledDispatch re-emits the ActivityDispatchTask and ScheduleToStart timeout task for | ||
| // a SCHEDULED activity. Retries fire at the retry time; first attempts dispatch now, lifted to | ||
| // honor any pending start_delay. | ||
| func (a *Activity) reissueScheduledDispatch(ctx chasm.MutableContext, attempt *activitypb.ActivityAttemptState) { |
Contributor
Author
There was a problem hiding this comment.
Refactoring due to lint complaining code complexity
fretz12
commented
Jun 18, 2026
| // paths after stamp bump so the old tasks are invalidated and replaced with the (possibly | ||
| // updated) timeouts. No-op unless the activity is in a status where a worker holds the task token | ||
| // (STARTED / CANCEL_REQUESTED / PAUSE_REQUESTED / RESET_REQUESTED). | ||
| func (a *Activity) reissueRunningAttemptTimers(ctx chasm.MutableContext, attempt *activitypb.ActivityAttemptState) { |
Contributor
Author
There was a problem hiding this comment.
Refactoring due to lint complaining code complexity
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
1 participant
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?
start_delayis now updatable viaUpdateActivityOptionsfor standalone activities. The new value is anchored to the originalschedule_time, so users can shorten it (including to 0, which dispatches immediately if the target is already past), extend it, or restore the original viaRestoreOriginal. Updates once the activity has left its delay window (first dispatch passed, or no longerSCHEDULED) are rejected withInvalidArgument. 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:
first_attempt_started_timeonActivityState, set once on the firstSCHEDULED → STARTEDand never updated on retries/resets. It is the canonical "has the first dispatch happened" discriminator.respectStartDelayhelper that lifts a candidate dispatch time toscheduleTime + start_delayuntil first pickup, and no-ops afterward. It drivesActivityDispatchTaskre-issuance so an unrelated update in the delay window no longer dispatches early, and gates theRestoreOriginalrestore so it never shows a stale value post-dispatch.reissueRunningAttemptTimers(StartToClose/Heartbeat) andreissueScheduledDispatch(Dispatch/ScheduleToStart).Also changes a pre-existing behavior where the update path anchored
ScheduleToClosetoscheduleTime + timeoutinstead offirstDispatchTime + timeout; it now uses the canonicalscheduleToCloseDeadline(), matchingTransitionScheduledandhasEnoughTimeForRetry.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_delaythroughUpdateActivityOptionscovers both run-now (set 0) and rescheduling with one primitive, using the same anchored-to-schedule-time semantics as creation.start_delayis a first-attempt parameter, sofirst_attempt_started_timekeeps every re-scheduling path from re-applying or restoring it after dispatch, where it would only mislead. TheScheduleToClosechange 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?