An agent executes a three-step pipeline: (1) update a configuration file via MCP tool, (2) push the change to a branch via MCP tool, (3) merge the branch via MCP tool. Step 2 succeeds, but step 3 fails with a merge conflict error. What rollback strategy should the agent implement?
Select an answer to reveal the explanation.
Short Explanation
A merge conflict isn't a data-integrity failure; it's a coordination problem. You should keep the branch and the pushed change, resolve the conflict if you can, or escalate to a human. Don't roll back completed steps unless someone explicitly tells you to.
Full Explanation
Rollback strategy in agentic pipelines depends on the nature of the failure. A merge conflict is not a signal that previous steps were wrong or harmful — it is a signal that concurrent changes created an incompatibility that requires resolution, not undoing.
The branch-deletion-and-restart approach is wrong. Deleting the branch removes valid, completed work without cause. The configuration update and branch push succeeded; those steps produced correct output. Starting over from step 1 wastes work that was already completed correctly and may introduce new inconsistencies if the environment changed between runs.
The correct posture is to leave the branch in place with the pushed change, resolve the merge conflict programmatically or escalate to a human, and do not revert the already-successful steps unless explicitly directed. When the merge step fails with a merge conflict, preserve the work from the configuration update and branch push (the branch with the configuration change is safe and correct), do not roll back completed steps (there is nothing to roll back — the prior steps are not the cause of the failure), and address the conflict. The agent should attempt programmatic conflict resolution if it has the context and capability to do so safely. If the conflict requires human judgment (e.g., overlapping semantic changes), escalate to a human rather than guessing.
The revert-the-configuration-change-and-retry approach is wrong. Reverting the configuration file change from the first step is unnecessary — that change is correct. Pushing a revert commit to resolve a merge conflict with main does not fix the conflict; it just changes the content on the branch. And it destroys the intended change that the entire pipeline was built to make. This conflates addressing a merge conflict with abandoning the task.
The force-push-main-to-previous-commit approach is wrong and dangerous. Force-pushing main to a previous commit overwrites repository history for all collaborators, deletes any commits that merged to main after the agent's branch was created, and is a destructive irreversible action. This is never an appropriate automated agent action and would require explicit human authorization even if attempted manually.