There's now a PR for this: #11326. Since this issue has been open a while and the history is scattered across repos, a short summary for anyone following:

The field already exists in the API as SchedulePolicies.keep_original_workflow_id (Adding support for as-is for scheduled workflow id api#357, merged Feb 2024), so no proto change is needed.
It was implemented server-side in Allow client to request not to add timestamp to scheduled workflow id #5447 and partially reverted a few days later in Partial revert of #5447 #5480 — "we're going to implement it in a slightly different way." The field has been accepted and silently ignored since.
Support as-is for scheduled workflow ID features#727 (SDK support) was closed as unprioritized pending that server work, and [Feature Request] Support as-is for scheduled workflow ID cli#910 was closed as not-planned and routed here.

#11326 is an attempt at that "slightly different way": version-gated in the V1 scheduler so recorded histories replay unchanged, implemented in the CHASM scheduler too, with ALLOW_ALL still appending a timestamp since concurrent runs can't share an id. Functional coverage runs against both schedulers.

Two open design questions for the schedules team are in a comment on the PR — the main one being that REJECT_DUPLICATE (added in #8035, after the original attempt) has to be relaxed for opted-in schedules or the field can't be honored at all.

@tsurdilo — flagging since you filed this.

Uh oh!

Schedules - add option for execution workflowid to be "as-is" (not unique per run) #4795

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions