Limits of DisCloud Rollback: Database Schema and Environment Variable Consistency

When a deployment on DisCloud fails, the platform’s web‑based log viewer aggregates the agent’s output, showing status messages, timestamps, and a truncated snippet of the last executed command. The UI offers a Rollback button that attempts to revert the site to the previous successful deployment, but the logs do not clearly indicate whether the rollback succeeded or if any files remain in an inconsistent state.

The current documentation does not specify whether the rollback process restores database schema changes or environment variable updates. This ambiguity can leave an application in a partially updated state after a failed deployment, potentially causing runtime errors or data inconsistencies that are hard to trace back to the deployment event.

Given this uncertainty, I need to understand the exact behavior of the rollback feature and how to verify its success through logs or other evidence. Specifically:

• Does DisCloud’s rollback preserve database schema changes made during the failed deployment?
• Are environment variable updates reverted to the previous state when a rollback is performed?
• Which log entries or UI indicators can confirm that a rollback has fully restored the application and its associated services to a consistent state?