Remove .gitmodules (#422)

* Remove .gitmodules

* gen openapi

Author: ShahabT

.gitmodules

@@ -3945,7 +3945,7 @@
         "BUILD_ID_TASK_REACHABILITY_UNREACHABLE"
       ],
       "default": "BUILD_ID_TASK_REACHABILITY_UNSPECIFIED",
-      "description": "Specifies which category of tasks may reach a versioned worker of a certain Build ID.\n\nTask Reachability is eventually consistent; there may be a delay until it converges to the most\naccurate value but it is designed in a way to take the more conservative side until it converges.\nFor example REACHABLE is more conservative than CLOSED_WORKFLOWS_ONLY.\n\nNote: future activities who inherit their workflow's Build ID but not its Task Queue will not be\naccounted for reachability as server cannot know if they'll happen as they do not use\nassignment rules of their Task Queue. Same goes for Child Workflows or Continue-As-New Workflows\nwho inherit the parent/previous workflow's Build ID but not its Task Queue. In those cases, make\nsure to query reachability for the parent/previous workflow's Task Queue as well.\n\n - BUILD_ID_TASK_REACHABILITY_UNSPECIFIED: Task reachability is not reported\n - BUILD_ID_TASK_REACHABILITY_REACHABLE: Build ID may be used by new workflows or activities (base on versioning rules), or there MAY\nbe open workflows or backlogged activities assigned to it.\n - BUILD_ID_TASK_REACHABILITY_CLOSED_WORKFLOWS_ONLY: Build ID does not have open workflows and is not reachable by new workflows,\nbut MAY have closed workflows within the namespace retention period.\nNot applicable to activity-only task queues.\n - BUILD_ID_TASK_REACHABILITY_UNREACHABLE: Build ID is not used for new executions, nor it has been used by any existing execution\nwithin the retention period."
+      "description": "Specifies which category of tasks may reach a versioned worker of a certain Build ID.\n\nTask Reachability is eventually consistent; there may be a delay (up to few minutes) until it\nconverges to the most accurate value but it is designed in a way to take the more conservative\nside until it converges. For example REACHABLE is more conservative than CLOSED_WORKFLOWS_ONLY.\n\nNote: future activities who inherit their workflow's Build ID but not its Task Queue will not be\naccounted for reachability as server cannot know if they'll happen as they do not use\nassignment rules of their Task Queue. Same goes for Child Workflows or Continue-As-New Workflows\nwho inherit the parent/previous workflow's Build ID but not its Task Queue. In those cases, make\nsure to query reachability for the parent/previous workflow's Task Queue as well.\n\n - BUILD_ID_TASK_REACHABILITY_UNSPECIFIED: Task reachability is not reported\n - BUILD_ID_TASK_REACHABILITY_REACHABLE: Build ID may be used by new workflows or activities (base on versioning rules), or there MAY\nbe open workflows or backlogged activities assigned to it.\n - BUILD_ID_TASK_REACHABILITY_CLOSED_WORKFLOWS_ONLY: Build ID does not have open workflows and is not reachable by new workflows,\nbut MAY have closed workflows within the namespace retention period.\nNot applicable to activity-only task queues.\n - BUILD_ID_TASK_REACHABILITY_UNREACHABLE: Build ID is not used for new executions, nor it has been used by any existing execution\nwithin the retention period."
     },
     "v1CalendarSpec": {
       "type": "object",

openapi/openapiv2.json

@@ -81,9 +81,9 @@ enum TaskReachability {
 
 // Specifies which category of tasks may reach a versioned worker of a certain Build ID.
 //
-// Task Reachability is eventually consistent; there may be a delay until it converges to the most
-// accurate value but it is designed in a way to take the more conservative side until it converges.
-// For example REACHABLE is more conservative than CLOSED_WORKFLOWS_ONLY.
+// Task Reachability is eventually consistent; there may be a delay (up to few minutes) until it
+// converges to the most accurate value but it is designed in a way to take the more conservative
+// side until it converges. For example REACHABLE is more conservative than CLOSED_WORKFLOWS_ONLY.
 //
 // Note: future activities who inherit their workflow's Build ID but not its Task Queue will not be
 // accounted for reachability as server cannot know if they'll happen as they do not use

temporal/api/enums/v1/task_queue.proto

@@ -563,17 +563,18 @@ service WorkflowService {
     // Use this API to manage Worker Versioning Rules for a given Task Queue. There are two types of
     // rules: Build ID Assignment rules and Compatible Build ID Redirect rules.
     //
-    // Assignment rules are used to assign a Build ID for a new execution when it starts. Its primary
-    // use case is to specify the latest Build ID but it has powerful features for gradual rollout
+    // Assignment rules determine how to assign new executions to a Build IDs. Their primary
+    // use case is to specify the latest Build ID but they have powerful features for gradual rollout
     // of a new Build ID.
     //
-    // Once a Build ID is assigned to a workflow execution and it completes its first Workflow Task,
+    // Once a workflow execution is assigned to a Build ID and it completes its first Workflow Task,
     // the workflow stays on the assigned Build ID regardless of changes in assignment rules. This
     // eliminates the need for compatibility between versions when you only care about using the new
     // version for new workflows and let existing workflows finish in their own version.
     //
-    // Activities, Child Workflows and Continue-as-New executions have the option to inherit their
-    // parent/previous workflow or use the latest assigment rules to independently select a Build ID.
+    // Activities, Child Workflows and Continue-as-New executions have the option to inherit the
+    // Build ID of their parent/previous workflow or use the latest assignment rules to independently
+    // select a Build ID.
     //
     // Redirect rules should only be used when you want to move workflows and activities assigned to
     // one Build ID (source) to another compatible Build ID (target). You are responsible to make sure