What causes "failed to get plan" in bytebase/bytebase?

Inspect the wrapped root cause and restore metadata DB connectivity or fix the underlying query error.

failed to get plan

Error message

failed to get plan

What it means

RunOnce wraps a store error from GetPlan when fetching the issue's linked plan (FindPlanMessage{ProjectID, UID}). The wrap keeps the underlying metadata store failure with context 'failed to get plan'. A nil plan is handled separately ('plan not found'), so this always indicates a real store/query failure.

Source

Thrown at backend/runner/reviewrun/rule_executor.go:53

		dbFactory:    dbFactory,
	}
}

// RunOnce implements Executor.
func (e *RuleExecutor) RunOnce(ctx context.Context, projectID string, issueUID int64) error {
	issue, err := e.store.GetIssue(ctx, &store.FindIssueMessage{ProjectIDs: []string{projectID}, UID: &issueUID})
	if err != nil {
		return errors.Wrapf(err, "failed to get issue")
	}
	if issue == nil {
		return errors.Errorf("issue %d not found in project %s", issueUID, projectID)
	}
	if issue.PlanUID == nil {
		return errors.Errorf("issue %d has no plan", issueUID)
	}
	plan, err := e.store.GetPlan(ctx, &store.FindPlanMessage{ProjectID: projectID, UID: issue.PlanUID})
	if err != nil {
		return errors.Wrapf(err, "failed to get plan")
	}
	if plan == nil {
		return errors.Errorf("plan %d not found in project %s", *issue.PlanUID, projectID)
	}
	project, err := e.store.GetProjectByResourceID(ctx, projectID)
	if err != nil {
		return errors.Wrapf(err, "failed to get project")
	}
	if project == nil {
		return errors.Errorf("project %s not found", projectID)
	}

	databaseGroup, err := plancheck.GetDatabaseGroupForPlan(ctx, e.store, plan, nil)
	if err != nil {
		return errors.Wrapf(err, "failed to get database group for plan")
	}
	// DeriveReviewTargets, not DeriveCheckTargets: review must evaluate every
	// (spec, target) unit, so the CI sampling limit does not apply.

View on GitHub (pinned to 1870550677)

Solutions

Inspect the wrapped root cause and restore metadata DB connectivity or fix the underlying query error.
Rely on the scheduler's retry; transient store failures recover on subsequent ticks.
Check server logs and metadata Postgres health for the failing plan query.

Defensive patterns

Strategy: retry

Validate before calling

if err := ctx.Err(); err != nil { return err }
// ensure issue.PlanUID is non-nil before the GetPlan call

Try / catch

if strings.Contains(err.Error(), "failed to get plan") {
    // log errors.Unwrap(err) for the store root cause; retry on next tick
}

Prevention

Use bounded context timeouts with retry/backoff in the scheduler loop.
Distinguish wrapped store errors (retryable) from nil-plan results (permanent) in logs.
Monitor metadata Postgres health to catch query failures before they starve the scheduler.

When it happens

Trigger: e.store.GetPlan returns a non-nil error while the review-run scheduler resolves issue.PlanUID during RunOnce.

Common situations: Metadata DB connectivity loss during scheduler execution; context cancellation/timeouts under load; corrupted plans table causing query errors.

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 bytebase/bytebase@1870550677 (2026-09-06). Data as JSON: /api/errors/2b9b4294199a916e. Report an issue: GitHub.