|
| 1 | +<?php |
| 2 | + |
| 3 | +declare(strict_types=1); |
| 4 | + |
| 5 | +namespace Temporal\Common\Versioning; |
| 6 | + |
| 7 | +/** |
| 8 | + * Specifies when a workflow might move from a worker of one Build Id to another. |
| 9 | + * |
| 10 | + * Versioning Behavior specifies if and how a workflow execution moves between Worker Deployment |
| 11 | + * Versions. The Versioning Behavior of a workflow execution is typically specified by the worker |
| 12 | + * who completes the first task of the execution, but is also overridable manually for new and |
| 13 | + * existing workflows (see VersioningOverride). |
| 14 | + * Experimental. Worker Deployments are experimental and might significantly change in the future. |
| 15 | + * |
| 16 | + * @see \Temporal\Api\Enums\V1\VersioningBehavior |
| 17 | + * |
| 18 | + * @since SDK 2.16.0 |
| 19 | + * @since RoadRunner 2025.1.3 |
| 20 | + * @internal Experimental |
| 21 | + */ |
| 22 | +enum VersioningBehavior: int |
| 23 | +{ |
| 24 | + /** |
| 25 | + * An unspecified versioning behavior. By default, workers opting into worker versioning will be |
| 26 | + * required to specify a behavior. |
| 27 | + */ |
| 28 | + case Unspecified = 0; |
| 29 | + |
| 30 | + /** |
| 31 | + * The workflow will be pinned to the current Build ID unless manually moved. |
| 32 | + * |
| 33 | + * Workflow will start on the Current Deployment Version of its Task Queue, and then |
| 34 | + * will be pinned to that same Deployment Version until completion (the Version that |
| 35 | + * this Workflow is pinned to is specified in `versioning_info.version`). |
| 36 | + * This behavior eliminates most of compatibility concerns users face when changing their code. |
| 37 | + * Patching is not needed when pinned workflows code change. |
| 38 | + * Can be overridden explicitly via `UpdateWorkflowExecutionOptions` API to move the |
| 39 | + * execution to another Deployment Version. |
| 40 | + * Activities of `Pinned` workflows are sent to the same Deployment Version. Exception to this |
| 41 | + * would be when the activity Task Queue workers are not present in the workflow's Deployment |
| 42 | + * Version, in which case the activity will be sent to the Current Deployment Version of its own |
| 43 | + * task queue. |
| 44 | + */ |
| 45 | + case Pinned = 1; |
| 46 | + |
| 47 | + /** |
| 48 | + * The workflow will automatically move to the latest version (default Build ID of the task queue) |
| 49 | + * when the next task is dispatched. |
| 50 | + * |
| 51 | + * Workflow will automatically move to the Current Deployment Version of its Task Queue when the |
| 52 | + * next workflow task is dispatched. |
| 53 | + * AutoUpgrade behavior is suitable for long-running workflows as it allows them to move to the |
| 54 | + * latest Deployment Version, but the user still needs to use Patching to keep the new code |
| 55 | + * compatible with prior versions for changed workflow types. |
| 56 | + * Activities of `AUTO_UPGRADE` workflows are sent to the Deployment Version of the workflow |
| 57 | + * execution (as specified in versioning_info.version based on the last completed |
| 58 | + * workflow task). Exception to this would be when the activity Task Queue workers are not |
| 59 | + * present in the workflow's Deployment Version, in which case, the activity will be sent to a |
| 60 | + * different Deployment Version according to the Current Deployment Version of its own task |
| 61 | + * queue. |
| 62 | + * Workflows stuck on a backlogged activity will still auto-upgrade if the Current Deployment |
| 63 | + * Version of their Task Queue changes, without having to wait for the backlogged activity to |
| 64 | + * complete on the old Version. |
| 65 | + */ |
| 66 | + case AutoUpgrade = 2; |
| 67 | + |
| 68 | + public static function tryFromName(?string $name): ?self |
| 69 | + { |
| 70 | + return match ($name) { |
| 71 | + 'Unspecified', null => self::Unspecified, |
| 72 | + 'Pinned' => self::Pinned, |
| 73 | + 'AutoUpgrade' => self::AutoUpgrade, |
| 74 | + default => null, |
| 75 | + }; |
| 76 | + } |
| 77 | +} |
0 commit comments