Auto-Retry Deployments
If a package deployment fails, you can configure the system to retry the deployments automatically. By enabling auto-retry for deployments in ThingWorx Software Content Management in ThingWorx Utilities, you allow users to create deployments that are automatically retried upon failure or time-out.
To monitor deployments and automatic retries, double-click the deployment in the Deployments table to navigate to the View Assets For Deployment page. For each target asset, this page displays the status of a selected deployment and timestamps for the downloading and installing states.
Auto-Retries Attempted—If the deployment has been created with a finite number of maximum auto retry count, then this column shows the retries attempted / max retry count. If the deployment has auto retry attempts set to Unlimited, then this column shows the retries attempted.
How Auto-Retry Works
When a deployment fails and is auto-retried, it goes through multiple states as described in the following table:
State
Description
Pending Retry
The delivery target is in the pending retry state when it waits for the server to start the retry. If the auto retry settings (Interval or Window) have been applied for the deployment, the delivery target will wait in the pending retry state until the next auto retry time has been reached. Below are some examples to understand the behavior:
1. Interval: 30 min
Window: 10:00 — 18:00
Days: Monday, Tuesday
If the delivery target fails on Monday at 09:00, the next auto retry will be attempted on Monday at 10:00.
2. Interval: 30 min
Window: 10:00 – 18:00
Days: Monday, Tuesday
If the delivery target fails on Monday at 13:00, the next auto retry will be attempted on Monday at 13:30
3. Interval: 30 min
Window: 10:00 — 18:00
Days: Monday, Tuesday
If the delivery target fails on Monday at 19:00, the next auto retry will be attempted on Tuesday at 10:00.
* 
The scan to find delivery targets in pending retry state is performed as per the scan rate mentioned in Auto-Retry Rate under Auto-Retry configuration. By default, it is 30 sec. If it is set to some higher value (for example 1 hour) than the auto retry interval defined while creating a deployment (for example 30 min), the delivery target will not be attempted for retry in 30 min and will only be retried after the next scan happens.
Retrying
The “retrying” state indicates that the server is retrying the deployment.
During a successful retry, the deployment of a package goes from the “retrying” state to the “completed” state.
If there is a failed retry, the transition to another state depends on the state during which the process failed. Consider the following scenarios:
For a file-based package, during the “notifying” state, if the edge device does not respond for a specified time period, the deployment transitions directly to the “aborted” state. If the notification fails for any other reason, the deployment transitions to the “failed” state.
For a file-based package, during the “downloading” state, if the download times out or is interrupted by a network event and the download fails, the deployment transitions to the “failed” or “aborted” state.
* 
Note the following points:
If a deployment to an agent times out or is interrupted and the download has not started yet, the deployment to that agent will be started over again from the “notifying” state.
If a deployment times out or is interrupted and the file has been partially downloaded to an agent when the deployment to that agent fails, the deployment to that agent will start from the “notifying” state. However, when the deployment enters the “downloading” state of the retry, the download resumes.
If a deployment fails after a file has been completely downloaded or if an MD5 check fails on the downloaded file, the deployment starts over and the entire file will be downloaded again.
If the user aborts the deployment, no retries are performed. The delivery target transitions directly to the “Canceled by User” state.
Was this helpful?