Skip to content

Add start delay field to StartActivityExecutionRequest#767

Merged
fretz12 merged 3 commits intomasterfrom
fredtzeng/saa-start-delay
Apr 24, 2026
Merged

Add start delay field to StartActivityExecutionRequest#767
fretz12 merged 3 commits intomasterfrom
fredtzeng/saa-start-delay

Conversation

@fretz12
Copy link
Copy Markdown
Contributor

@fretz12 fretz12 commented Apr 21, 2026

What changed?
Added a start_delay field to StartActivityExecutionRequest in the proto definition and updated the OpenAPI specs accordingly.

Why?
To allow callers to specify a delay before the first standalone activity task is dispatched, matching the existing start delay capability available for workflow-started activities.

@fretz12 fretz12 changed the title Fredtzeng/saa start delay Add start delay field to StartActivityExecutionRequest Apr 21, 2026
@fretz12 fretz12 force-pushed the fredtzeng/saa-start-delay branch from b293829 to 30651e4 Compare April 21, 2026 22:26
@fretz12 fretz12 marked this pull request as ready for review April 21, 2026 22:41
@fretz12 fretz12 requested review from a team April 21, 2026 22:41
Comment thread temporal/api/workflowservice/v1/request_response.proto Outdated
@fretz12 fretz12 force-pushed the fredtzeng/saa-start-delay branch from 30651e4 to 47fdfcd Compare April 22, 2026 23:07
@fretz12 fretz12 requested a review from Sushisource April 22, 2026 23:12
repeated temporal.api.common.v1.Link links = 20;
// Options for handling conflicts when using ACTIVITY_ID_CONFLICT_POLICY_USE_EXISTING.
temporal.api.common.v1.OnConflictOptions on_conflict_options = 21;
// Time to wait before dispatching the activity.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: this is a bit clearer to me and matches the language in the workflow start_delay comments.

Suggested change
// Time to wait before dispatching the activity.
// Time to wait before dispatching the first activity task.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm going to make a bit clearer. @Sushisource had previously mentioned the first sounded confusing.

// Time to wait before dispatching the activity. This delay is not applied to retry attempts.

LMK thoughts

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per discussion Dan still prefers the task word. "So the more explicit/technical version made sense to me; for "activities" themselves, users are familiar with "starting" them, but even there there's confusion with "scheduling" , so I thought best not to add a 3rd verb"

@fretz12 fretz12 merged commit 3a30adc into master Apr 24, 2026
4 checks passed
@fretz12 fretz12 deleted the fredtzeng/saa-start-delay branch April 24, 2026 17:07
spkane31 pushed a commit that referenced this pull request Apr 24, 2026
**What changed?**
Added a start_delay field to StartActivityExecutionRequest in the proto
definition and updated the OpenAPI specs accordingly.

**Why?**
To allow callers to specify a delay before the first standalone activity
task is dispatched, matching the existing start delay capability
available for workflow-started activities.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants