3 patterns for this goal
Rollback agents fail to actually restore working behavior because they treat orchestrator-level deployment success (pods are Ready, the rollout state is Succeeded) as sufficient validation that the application is healthy, ignore stateful side effects (schema changes, cache invalidation, feature-flag resets) that the rollback does not undo, or lose a critical override flag (do-not-revert marker on a hotfix) at the handoff boundary so an automated rollback reverts a separate, concurrent fix along with the bad change. Three patterns are documented here, spanning orchestrator-state vs. application-health confusion, stateful-side-effect inconsistency, and protection-flag handoff loss. Each failure allows a rollback to be reported as successful when it has not actually restored the service to a working state — the change is reverted, but the state is corrupted, or the readiness probe passes while errors continue, or a concurrent hotfix gets collateral reverted — so the incident remains unresolved even though the automated system has marked itself complete.
Rollback failures occur because an agent treats a proxy signal (orchestrator status, code-version reversion, lack of a protection flag) as equivalent to the actual outcome the rollback was supposed to achieve (the incident is resolved). Orchestrator status tells you whether the artifact reversion succeeded technically; it does not tell you whether the application is healthy. Code rollback tells you whether the prior artifact is back in the live path; it does not tell you whether that artifact is compatible with the state the bad version left behind. Absence of a protection-flag field tells you nothing about whether a field should exist. All three failures share the pattern that a rollback can be technically complete and still fail to restore working behavior because the agent never validated the outcome against the original problem. The shared mitigation across all three patterns is verification gates that separate concerns: (1) orchestrator completion is a precondition to check application health, not a substitute; (2) stateful side effects must be explicitly inventoried and remedied as part of the rollback plan, not assumed to be harmless; (3) protection flags must be structured fields the rollback logic reads, not optional commentary that can be lost at handoff boundaries.
Rollback agents commonly use orchestrator state (replicas at target revision, readiness probe passing) as the success criterion, but orchestrator state describes only whether the artifact was successfully reverted — not whether the application is actually healthy. If the application depends on state not reset by artifact-only rollback (an in-process cache, a feature flag set at startup, an unrolled-back dependency), the orchestrator success is premature. See Orchestrator Status Mistaken for Application Health After Rollback.
Not with artifact rollback alone. Code rollback reverts the artifact, but schema changes persist, leaving the rolled-back code incompatible with the schema the bad version introduced. A safe rollback plan must include either reverting the migration (if safe) or validating schema backward-compatibility. See Partial Rollback State Corruption.
If the hotfix is marked with a do-not-revert flag only in deploy commentary, not in a structured field the rollback agent reads, the rollback will revert the hotfix along with the bad change, re-introducing the separate incident the hotfix had just fixed. The deploy agent’s protection note is lost at the handoff boundary. See Multi-Agent Handoff Drops Override Flag Between Deploy and Rollback Agent.
| Pattern | Mechanism |
|---|---|
| Multi-Agent Handoff Drops Override Flag Between Deploy and Rollback Agent | Deploy agent’s protection note exists only in commentary, invisible to rollback agent’s structured decision logic |
| Orchestrator Status Mistaken for Application Health After Rollback | Rollback marked successful based on orchestrator status, without confirming the original symptom metric has recovered |
| Partial Rollback State Corruption | Code rolled back but stateful side effects (schema changes, message-format changes) from bad version persist, corrupting state |
Total: 3 patterns
A Deploy Agent Notes in Its Free-Text Reasoning That a Just-Deployed Change Includes a Manual Hotfix Applied to Address a Separate, Concurrent Incident, but This Note Is Never Written to a Structured Field the Downstream Rollback Agent Reads, So an Automated Rollback Triggered by an Unrelated Regression Reverts the Hotfix Along With the Bad Change
Rollback Agent Declares a Rollback Successful Based on the Deployment Orchestrator Reporting "Rollout Succeeded," Without Verifying That the Application Is Actually Serving Traffic Correctly at the Prior Version
Agent Initiates an Automated Rollback of a Bad Deployment Without Accounting for Stateful Side Effects (Schema Changes, Queued Messages, Cached Data) Already Caused by the Bad Version