plandex-ai/plandex · error
Error applying plan:
Error message
Error applying plan:
What it means
The final db.ApplyPlan call inside the write-lock ExecRepoOperation failed, so the handler returns 500 'Error applying plan: <detail>'. Because ClearRepoOnErr is set, the plan's internal git repo is cleared on failure to avoid a corrupt intermediate state — pending results are left unapplied.
Source
Thrown at app/server/handlers/plans_changes.go:242
Scope: db.LockScopeWrite,
Ctx: ctx,
CancelFn: cancel,
ClearRepoOnErr: true,
}, func(repo *db.GitRepo) error {
return db.ApplyPlan(repo, ctx, db.ApplyPlanParams{
OrgId: auth.OrgId,
UserId: auth.User.Id,
BranchName: branch,
Plan: plan,
CurrentPlanState: currentPlan,
CurrentPlanStateParams: ¤tPlanParams,
CommitMsg: commitMsg,
})
})
if err != nil {
log.Printf("Error applying plan: %v\n", err)
http.Error(w, "Error applying plan: "+err.Error(), http.StatusInternalServerError)
return
}
w.Write([]byte(commitMsg))
log.Println("Successfully applied plan", planId)
}
func RejectAllChangesHandler(w http.ResponseWriter, r *http.Request) {
log.Println("Received request for RejectAllChangesHandler")
auth := Authenticate(w, r, true)
if auth == nil {
return
}
vars := mux.Vars(r)
planId := vars["planId"]View on GitHub (pinned to e2d772072e)
Solutions
- Check the appended error detail and server log for the failing git/DB step
- Remove stale .git lock files in the plan repo if a previous crash left them
- Ensure no concurrent apply/reject is running on the same plan/branch, then retry
- Verify disk space and Postgres health; if the repo was cleared, re-apply from pending results
Example fix
null
Defensive patterns
Strategy: retry
Validate before calling
null
Type guard
null
Try / catch
const res = await fetch(applyUrl, opts);
if (res.status === 500 && (await res.text()).includes('Error applying plan')) {
// repo may have been cleared (ClearRepoOnErr): check plan state, then re-apply
const state = await fetch(currentPlanUrl);
// verify pending results still exist before retrying
} Prevention
- Only one apply per plan/branch at a time; lock client-side
- Keep adequate disk space and clean stale git lock files on the server
- Keep the request context alive (no premature aborts) during apply
- After a failed apply, re-fetch plan state before retrying
When it happens
Trigger: Git operations inside ApplyPlan fail (checkout/merge conflict, dirty repo, detached head); DB write of the applied context/files fails; context cancellation mid-apply; lock contention forcing an error with repo clear.
Common situations: Two clients applying simultaneously; plan file conflicts with current branch state; disk full or git lock files left by a crashed process; Postgres failure mid-commit; user navigated away and context cancelled.
Related errors
- Error getting current plan state:
- Error rejecting all changes:
- Error rejecting result:
- Error error updating contexts:
- Error deleting contexts:
AI-assisted analysis of plandex-ai/plandex@e2d772072e (2026-09-05).
Data as JSON: /api/errors/ee85f8482962361a.
Report an issue: GitHub.