Merge pull request #2039 from OctopusDeploy/sast/rpcretry

Review and update docs for RPC retry feature.

src/pages/docs/infrastructure/deployment-targets/machine-policies.mdx

@@ -153,26 +153,25 @@ You can select a username/password account to perform automatic Tentacle updates
 ## Recover from communication errors with Tentacle \{#MachinePolicies-Recoverfromcommunicationerrorswithtentacle}
 
 :::div{.hint}
-Recovering from communication errors with Tentacle was gradually made available to **Cloud** customers from **Octopus 2023.3** onwards and will be made available to self-hosted customers in either 2023.4 or 2024.
+Recovering from communication errors with Tentacle is available to **Cloud** customers from **Octopus 2023.3** onwards and will be made available to self-hosted customers in a future release.
 :::
 
-Configure whether Octopus Deploy should re-attempt failed communication with a Tentacle for a set duration.
+You can configure whether Octopus Deploy should re-attempt failed communications with a Tentacle for a set duration when a network error occurs. This is particularly useful to reduce deployment failures that occur when Tentacle is on an unstable network connection.
 
-With this setting, if a network error occurs while Octopus Deploy is communicating with a Tentacle,
-- **When disabled**, the deployment, runbook run, or health check will fail.
-- **When enabled**, it will re-attempt communication with the Tentacle for the configured duration. However, continued network errors will cause a failure.
+- With this setting **Disabled**, if a network error occurs while Octopus Deploy is communicating with a Tentacle, the deployment, runbook run, or health check will fail.
+
+- With this setting **Enabled**, if a network error occurs, Octopus will re-attempt communication with the Tentacle for the amount of time configured. However, continued network errors will cause a failure.
 
-:::div{.warning}
-Using this setting with a Tentacle that runs on ephemeral storage (e.g., running Tentacle in Docker without a mount) will introduce the possibility that a script could run twice.
 
-It is recommended to run Tentacle on a persistent file system.
+:::div{.warning}
+Using this setting with a Tentacle that runs on ephemeral storage will introduce the possibility that a script could run twice. For example, when running Tentacle in Docker without a mount. It is recommended to run Tentacle on a persistent file system.
 :::
 
 ### Retry durations
-There are two configurable durations for setting the maximum amount of time allowed to re-attempt failed communication with a Tentacle:
+You can configure the amount of time allowed for Octopus to re-attempt failed communication with Tentacle. There are two duration configurations available:
 
 - **Deployment or Runbook Run**
-- **Health Check**
+- **Health Check** 
 
 :::figure
 ![](/docs/infrastructure/deployment-targets/images/recover-from-communication-errors-with-tentacle-durations.png "width=500")

src/pages/docs/projects/steps/conditions/index.mdx

@@ -167,7 +167,7 @@ This functionality is available on all other steps.
 ### Retries
 Enabling Retries gives you the ability to automatically retry a step if it fails, with up to three attempts. This feature is particularly useful when dealing with steps that commonly fail due to temporary or transient errors during deployment.
 
-You can also [recover from communication errors with a tentacle](/docs/infrastructure/deployment-targets/machine-policies/#MachinePolicies-Recoverfromcommunicationerrorswithtentacle).
+ You can also [recover from communication errors with a tentacle](/docs/infrastructure/deployment-targets/machine-policies/#MachinePolicies-Recoverfromcommunicationerrorswithtentacle) to reduce deployment failures that occur when Tentacle is on an unstable network connection.
 
 ### Timeouts
 When the configured Execution Timeout period has lapsed, the action will be cancelled.