Action Rollback

Two-Phase Commit (2PC) is a distributed consensus protocol that guarantees atomicity across multiple participants. It ensures all participants in a transaction either commit or abort together, providing a strong rollback guarantee.

• Phase 1 (Prepare): The coordinator asks all participants if they can commit. Participants vote 'Yes' (after writing to a log) or 'No'.
• Phase 2 (Commit/Rollback): If all vote 'Yes', the coordinator sends a commit command. If any vote 'No', it sends an abort command, triggering a rollback on all participants.
• Drawback: It is a blocking protocol; if the coordinator fails, participants can remain in an uncertain state, requiring manual intervention.

Checkpoint/Restore is a system-level recovery technique where the complete state of a process or system is periodically serialized and saved to persistent storage. This checkpoint serves as a snapshot from which execution can be resumed after a failure.

• Granularity: Can be applied at the process level (e.g., CRIU for containers) or application level (e.g., saving an agent's memory and execution context).
• Implementation: Often uses copy-on-write techniques to minimize performance overhead during state capture.
• Trade-off: Creates a tension between recovery point objective (frequency of checkpoints) and performance overhead.

Write-Ahead Logging (WAL) is a fundamental database durability and recovery protocol. The core rule is that any change to data files must be logged to a persistent, append-only log before the modification is applied. This log enables precise rollback.

• Rollback Process: To undo an uncommitted transaction, the database engine reads the WAL in reverse, applying compensation records or ignoring the transaction's log entries.
• Crash Recovery: After a system failure, the WAL is replayed (REDO) to restore committed changes and rolled back (UNDO) for uncommitted transactions.
• Ubiquity: The foundational mechanism for ACID transactions in systems like PostgreSQL, SQLite, and many distributed datastores.

Optimistic Concurrency Control (OCC) is a transaction management method that defers conflict detection until commit time. It operates on the 'optimistic' assumption that conflicts are rare, allowing transactions to proceed without locking, but requires a rollback mechanism if conflicts arise.

• Three Phases: Read (transaction records data versions), Modify (works on a private copy), Validate & Commit (checks for conflicts with other committed transactions).
• Rollback Trigger: If the validation phase detects a conflict (e.g., a 'read' version has changed), the transaction is aborted and rolled back entirely, and may be retried.
• Advantage: High performance in low-conflict environments, as it avoids locking overhead.

A state machine snapshot is a periodic capture of the complete, deterministic state of a state machine (e.g., a RAFT or actor-model-based agent). This allows the system to restart from the snapshot without replaying the entire log history.

• Relation to Rollback: While primarily for recovery, it can enable a form of coarse-grained rollback by reverting to a prior snapshot and discarding subsequent, potentially erroneous operations.
• Incremental Snapshots: Advanced implementations use incremental or differential snapshots to reduce storage and capture time.
• Use in Agent Systems: An autonomous agent can snapshot its internal reasoning state, tool-call history, and world model, allowing it to revert to a known-good cognitive point.

The most foundational example, where an agent executing a multi-step database update encounters a constraint violation or error on a later step. The system issues a ROLLBACK command, leveraging the database's Atomicity, Consistency, Isolation, Durability (ACID) properties to undo all changes made within the transaction boundary, restoring the database to its pre-transaction state. This is essential for maintaining data integrity when an agent's tool call sequence fails mid-execution.

In distributed, microservices-based architectures, a long-running business process (e.g., 'place order') is broken into a sequence of local transactions across services. If a subsequent step fails (e.g., payment service is down), the orchestrating agent executes compensating transactions—the semantic inverse of completed steps—such as 'cancel inventory reservation' or 'unlock customer credit'. This implements rollback in an eventually consistent system without a global transaction lock.

An agent tasked with deploying a software update or modifying system configuration writes to files or a registry. If a post-write validation check fails, the agent must revert the changes. This is achieved by:

• Versioned file systems: Restoring from a snapshot taken before the operation.
• Checkpointing: Re-applying a saved delta or backup.
• Two-phase writes: Writing to a temporary location first, then atomically swapping files upon success. Failure triggers deletion of the temp files, leaving the original state intact.

An agent performing a sequence of state-mutating API calls to external services (e.g., creating a cloud resource, then configuring it) must rollback if a later call fails. This requires the agent to:

1. Maintain a reverse operation log for each successful call (e.g., 'CreateVM' → logged 'DeleteVM' command).
2. Upon failure, execute the logged reverse commands in LIFO (Last-In, First-Out) order.
3. Handle cases where the reverse operation itself may fail, requiring escalation or manual intervention.

In embodied AI systems, a physical action may have irreversible consequences. Rollback here is often simulated or compensatory. For example:

• A robot arm places a component incorrectly. A rollback involves picking the component back up (if possible) or moving to a recovery pose.
• In sim-to-real training, a failed action in simulation is rolled back by resetting the physics engine to a prior state, allowing the agent to learn from the mistake without real-world cost.
• This highlights the difference between digital state reversion and physical world compensation.

A dialog agent maintaining internal belief state or context window may generate an incorrect assertion or take an erroneous logical step. Rollback involves:

• Reverting the internal reasoning chain to a prior checkpoint.
• Retracting the last user-facing message and issuing a correction.
• Clearing tool call history related to the faulty step from its context to prevent hallucination loops. This is crucial for maintaining conversational coherence and user trust when the agent self-corrects.

Dynamic replanning is the real-time modification of an agent's sequence of actions in response to errors, changing conditions, or new information. Unlike a simple retry, it involves formulating a new plan from the current state.

• Contrast with Rollback: While rollback reverts to a past state, dynamic replanning moves forward with a new strategy.
• Use Case: An autonomous delivery robot recalculating its route after encountering an unexpected road closure.

A compensating action is an operation designed to semantically undo the effects of a previously committed action, enabling forward recovery. It is the functional inverse of the original action.

• Key Difference: A rollback reverts system state; a compensating action applies a new, corrective action (e.g., issuing a refund to compensate for a processed charge).
• Architectural Pattern: Central to the Saga pattern for managing long-running, distributed transactions without locking resources.

State recovery is the mechanism by which an agent restores its internal operational context or the external system state to a known-good checkpoint after a failure. It is a broader concept than action rollback.

• Scope: Can involve restoring memory, session data, database snapshots, or environment variables.
• Implementation: Often relies on checkpoint/restore mechanisms or persistent write-ahead logs (WAL) to capture state at consistent intervals.

Plan repair is the process of modifying a partially executed or failed plan to still achieve the original goal, often by substituting actions, reordering steps, or relaxing constraints.

• Focus on Continuity: The objective is to salvage the existing plan where possible, rather than discarding it entirely.
• Techniques: May involve backtracking search to a prior decision point or constraint relaxation to find a feasible, if suboptimal, solution.

Fallback execution is a fault-tolerant strategy where a system switches to a predefined alternative action or simplified workflow when a primary operation fails or exceeds performance thresholds.

• Proactive Design: Requires pre-authoring alternative paths for critical operations.
• Common Pattern: Model cascading, where a request fails over from a large, accurate model to a smaller, faster one if the primary times out.

The Saga pattern is a design for managing long-running, distributed business transactions. It breaks the transaction into a sequence of local transactions, each with a corresponding compensating action for rollback.

• Eventual Consistency: Achieves reliability without distributed locks, using compensating transactions to undo completed steps if a later step fails.
• Contrast with 2PC: Unlike Two-Phase Commit (2PC), which seeks atomicity, Sagas manage forward recovery via business logic.