Interface: IUpdateWorkerBuildIdCompatibilityRequest
workflowservice.v1.IUpdateWorkerBuildIdCompatibilityRequest
Properties of an UpdateWorkerBuildIdCompatibilityRequest.
Implemented by
Properties
addNewBuildIdInNewDefaultSet
• Optional addNewBuildIdInNewDefaultSet: null | string
A new build id. This operation will create a new set which will be the new overall default version for the queue, with this id as its only member. This new set is incompatible with all previous sets/versions.
(-- api-linter: core::0140::prepositions=disabled aip.dev/not-precedent: In makes perfect sense here. --)
addNewCompatibleBuildId
• Optional addNewCompatibleBuildId: null | IAddNewCompatibleVersion
Adds a new id to an existing compatible set, see sub-message definition for more.
mergeSets
• Optional mergeSets: null | IMergeSets
Merge two existing sets together, thus declaring all build IDs in both sets compatible with one another. The primary set's default will become the default for the merged set. This is useful if you've accidentally declared a new ID as incompatible you meant to declare as compatible. The unusual case of incomplete replication during failover could also result in a split set, which this operation can repair.
namespace
• Optional namespace: null | string
UpdateWorkerBuildIdCompatibilityRequest namespace
promoteBuildIdWithinSet
• Optional promoteBuildIdWithinSet: null | string
Promote an existing build id within some set to be the current default for that set.
(-- api-linter: core::0140::prepositions=disabled aip.dev/not-precedent: Within makes perfect sense here. --)
promoteSetByBuildId
• Optional promoteSetByBuildId: null | string
Promote an existing set to be the current default (if it isn't already) by targeting an existing build id within it. This field's value is the extant build id.
(-- api-linter: core::0140::prepositions=disabled aip.dev/not-precedent: Names are hard. --)
taskQueue
• Optional taskQueue: null | string
Must be set, the task queue to apply changes to. Because all workers on a given task queue must have the same set of workflow & activity implementations, there is no reason to specify a task queue type here.