plandex-ai/plandex · error

error getting pending builds by path: %v

Error message

error getting pending builds by path: %v

What it means

This error comes from loadPendingBuilds in app/server/model/plan/build_load.go when the goroutine calling active.PendingBuildsByPath(orgId, userId, nil) gets a non-nil error computing which builds are pending for each file path in the plan. The error is logged as 'Error getting pending builds by path' and forwarded to errCh wrapped as 'error getting pending builds by path: %v', aborting the build-stream load. The root database/state error is always appended after the colon.

Source

Thrown at app/server/model/plan/build_load.go:80

			}
			modelContext = res

			errCh <- nil
		}()

		go func() {
			defer func() {
				if r := recover(); r != nil {
					log.Printf("panic in getPlanSettings: %v\n%s", r, debug.Stack())
					errCh <- fmt.Errorf("error getting plan settings: %v", r)
					runtime.Goexit() // don't allow outer function to continue and double-send to channel
				}
			}()
			res, err := active.PendingBuildsByPath(auth.OrgId, auth.User.Id, nil)

			if err != nil {
				log.Printf("Error getting pending builds by path: %v\n", err)
				errCh <- fmt.Errorf("error getting pending builds by path: %v", err)
				return
			}

			pendingBuildsByPath = res

			errCh <- nil
		}()

		go func() {
			defer func() {
				if r := recover(); r != nil {
					log.Printf("panic in getPlanSettings: %v\n%s", r, debug.Stack())
					errCh <- fmt.Errorf("error getting plan settings: %v", r)
					runtime.Goexit() // don't allow outer function to continue and double-send to channel
				}
			}()
			res, err := db.GetPlanSettings(plan)
			if err != nil {

View on GitHub (pinned to e2d772072e)

Solutions

  1. Inspect the underlying error after '%v' in the message and address that root cause (usually a DB query/connection failure).
  2. Check for stale active-build rows for this plan and clear them if the server was previously killed mid-build.
  3. Verify no other long-running operation is holding the plan's repo lock (ExecRepoOperation) causing timeouts; retry when idle.
  4. Confirm the plan and branch still exist on the server (plandex branches) and retry the request.
  5. Restart the Plandex server/DB if connection errors persist, then retry the build.

Example fix

// caller-side retry pattern for this transient load failure
for i := 0; i < 3; i++ {
    err := startPlanBuild(planId, branch)
    if err == nil || !strings.Contains(err.Error(), "error getting pending builds by path") {
        break
    }
    time.Sleep(2 * time.Second) // wait for DB/lock contention to clear, then retry
}
Defensive patterns

Strategy: retry

Validate before calling

// caller-side checks before starting the build
// plandex branches --plan <planId>   -> target branch exists
// ensure no other build/apply is running on the branch:
// plandex ps --plan <planId>
if planBusy(planId, branch) { return errors.New("plan already has an active operation; wait and retry") }

Try / catch

err := loadPlanBuild(planId, branch)
if err != nil && strings.Contains(err.Error(), "error getting pending builds by path") {
    // usually transient (DB/lock contention): retry with backoff
    select {
    case <-time.After(2 * time.Second):
        return loadPlanBuild(planId, branch)
    case <-ctx.Done():
        return ctx.Err()
    }
}

Prevention

When it happens

Trigger: Calling the plan build/stream API while PendingBuildsByPath fails - typically an internal DB query over active builds for the org/user fails, or plan/branch state is inconsistent so the pending-build lookup errors out.

Common situations: Postgres connectivity problems or lock contention while other operations hold the plan repo lock; orphaned/stale active-build rows from a previously crashed server; querying a plan branch that was deleted or renamed mid-request.

Understand the failure class

Background: Database query failed: Internal Server Error 500s wrapping SQL, Prisma, and connection failures — what to check first — this error's family across 16 libraries.

Related errors


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