Before starting a purge, the PurgingService runs a series of validation checks to determine whether it can safely remove versioning data within the specified cut-off date. Purge execution requires the following conditions to be true:
The PurgingService only supports database systems that are also supported for production use. The PurgingService does not support development-only database systems such as Solid and MySQL.
The DeploymentServer is active and the deployment topology is up-to-date.
No deployments are in progress. Because a deployment and a purge both affect snapshot data, consistency of data can be ensured only if all deployments are complete before the purge begins.
All processes whose projects were checked in before the purge cut-off date are complete. Processes whose projects have not deployed are regarded as incomplete and should not be purged.
For all initialized targets, the deployed snapshot date follows the purge cut-off date. In order to avoid deployment errors, a purge must never include the deployed snapshot.
No projects to be purged are scheduled for deployment.
If a purge attempt fails one or more validation checks, you can often pass these checks by setting an earlier purge cut-off date. For example, if a purge fails to execute because purge candidates include an undeployed project, supply an earlier cut-off date that removes the project from the purge and allows the purge to proceed.