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: &currentPlanParams,
			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

  1. Check the appended error detail and server log for the failing git/DB step
  2. Remove stale .git lock files in the plan repo if a previous crash left them
  3. Ensure no concurrent apply/reject is running on the same plan/branch, then retry
  4. 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

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


AI-assisted analysis of plandex-ai/plandex@e2d772072e (2026-09-05). Data as JSON: /api/errors/ee85f8482962361a. Report an issue: GitHub.