What causes "%v" in plandex-ai/plandex?

Read the server log line starting with 'Error:' for the full underlying cause (API error or panic stack)

%v

Error message

%v

What it means

Piped-data and note contexts get an LLM-generated name in goroutines whose results are collected over errCh. Any error from GenPipedDataName/GenNoteName — including a recovered panic with a stack trace — is surfaced verbatim as an HTTP 500 with the message being just err.Error() (hence the generic "%v").

Source

Thrown at app/server/handlers/context_helper.go:208

				name, err := model.GenNoteName(r.Context(), auth, plan, settings, orgUserConfig, clients, authVars, context.Body, context.SessionId)

				if err != nil {
					errCh <- fmt.Errorf("error generating name for note: %v", err)
					return
				}

				context.Name = name
				errCh <- nil
			}(context)
		}
	}
	if num > 0 {
		for i := 0; i < num; i++ {
			err := <-errCh
			if err != nil {
				log.Printf("Error: %v\n", err)
				http.Error(w, err.Error(), http.StatusInternalServerError)
				return nil, nil
			}
		}
	}

	ctx, cancel := context.WithCancel(r.Context())

	var loadRes *shared.LoadContextResponse
	var dbContexts []*db.Context

	err = db.ExecRepoOperation(db.ExecRepoOperationParams{
		OrgId:          auth.OrgId,
		UserId:         auth.User.Id,
		PlanId:         plan.Id,
		Branch:         branchName,
		Reason:         "load contexts",
		Scope:          db.LockScopeWrite,
		Ctx:            ctx,

View on GitHub (pinned to e2d772072e)

Solutions

Read the server log line starting with 'Error:' for the full underlying cause (API error or panic stack)
Verify LLM API keys/org auth vars configured for the plan are valid and have quota
Retry the load after provider recovery if it was a transient 5xx/429
Trim oversized piped content; report the panic to Plandex if it's a framework bug

Defensive patterns

Strategy: try-catch

Validate before calling

if len(pipedBody) > 100_000 {
    return fmt.Errorf("piped content too large for auto-naming; provide a name explicitly")
}

Try / catch

resp, err := doLoad(req)
if err != nil && strings.HasPrefix(err.Error(), "error generating name for") {
    // LLM naming call failed: check API keys/quota, retry with backoff
    return retryWithBackoff(doLoad)
}

Prevention

Keep LLM API keys and auth vars valid and funded
Trim piped content; supply explicit names to skip LLM naming
Watch provider status for 429/5xx storms before bulk loads
Report panics with the server's stack trace to maintainers

When it happens

Trigger: GenPipedDataName or GenNoteName fails (LLM API error, auth/invalid API key, rate limit, timeout, cancelled request) or panics inside the naming goroutine while loading piped data or notes.

Common situations: Expired/invalid LLM API keys; provider outages or 429s; very long piped content blowing the naming model's context; nil-pointer panic in a custom model integration.

Related errors

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