plandex-ai/plandex · error
Error getting plan convo:
Error message
Error getting plan convo:
What it means
ListConvoHandler returns this 500 when the ExecRepoOperation wrapping db.GetPlanConvo fails while loading a plan's conversation messages. The operation runs under a repo read lock, so failures include lock/context problems as well as storage read errors. The underlying error is appended to the response and logged.
Source
Thrown at app/server/handlers/plans_convo.go:59
Reason: "list convo",
Scope: db.LockScopeRead,
Ctx: ctx,
CancelFn: cancel,
}, func(repo *db.GitRepo) error {
res, err := db.GetPlanConvo(auth.OrgId, planId)
if err != nil {
return err
}
convoMessages = res
return nil
})
if err != nil {
log.Println("Error getting plan convo: ", err)
http.Error(w, "Error getting plan convo: "+err.Error(), http.StatusInternalServerError)
return
}
apiConvoMessages := make([]*shared.ConvoMessage, len(convoMessages))
for i, convoMessage := range convoMessages {
apiConvoMessages[i] = convoMessage.ToApi()
}
bytes, err := json.Marshal(apiConvoMessages)
if err != nil {
log.Println("Error marshalling plan convo: ", err)
http.Error(w, "Error marshalling plan convo: "+err.Error(), http.StatusInternalServerError)
return
}
log.Println("Successfully processed request for ListConvoHandler")
w.Write(bytes)View on GitHub (pinned to e2d772072e)
Solutions
- Check the server log for the underlying GetPlanConvo/ExecRepoOperation error
- Verify the planId and branch path params refer to an existing plan and branch
- Check for lock contention or request-context cancellation from slow clients/proxies
- Confirm the plans storage volume (git repo dir) and database are mounted and healthy
Defensive patterns
Strategy: retry
Validate before calling
if (!planId || typeof planId !== 'string') throw new Error('planId required');
const plan = await getPlan(planId); // 404 here means convo lookup will also fail Try / catch
try {
const convo = await listPlanConvo(planId, branch);
} catch (e) {
if (/Error getting plan convo/.test(e.message)) {
// transient lock/DB failure — retry with backoff
return withBackoff(() => listPlanConvo(planId, branch), 3);
}
throw e;
} Prevention
- Keep request timeouts on proxies longer than expected repo-lock wait times
- Refresh plan existence before long UI sessions that read convo
- Retry idempotent GETs on 500 with exponential backoff
- Alert on repeated 'Error getting plan convo' log lines
When it happens
Trigger: GET of a plan's convo where the repo operation fails: request context cancelled while waiting on the repo lock, plan branch/repo storage missing or corrupted, database read of convo messages fails, or the plan was deleted mid-request.
Common situations: Concurrent plan deletion or branch lock contention causing context cancellation; missing or unreadable plans storage directory/volume; Postgres read errors; stale planId from a deleted plan.
Related errors
- Error updating plan tokens:
- Error getting plan summaries:
- Error deleting draft plans:
- error getting current plan state: %v
- error getting current plan state: %v
AI-assisted analysis of plandex-ai/plandex@e2d772072e (2026-09-05).
Data as JSON: /api/errors/331b786a5fb29b11.
Report an issue: GitHub.