plandex-ai/plandex · error

fast apply validation failed: %w

Error message

fast apply validation failed: %w

What it means

The single-attempt buildValidateLoop run on the fast-apply output returned a non-nil, non-cancellation error. It is wrapped with %w so the underlying cause (typically an LLM API failure inside the validation loop) is preserved. This differs from error 679, which is a validation 'problem' result rather than a hard error.

Source

Thrown at app/server/model/plan/build_race.go:184

				proposedContent: proposedContent,
				desc:            desc,
				reasons:         reasons,

				// just validate since we're already building replacements in parallel
				maxAttempts:                1,
				validateOnlyOnFinalAttempt: true,
				isInitial:                  false,
				sessionId:                  sessionId,
			})

			if err != nil {
				if errors.Is(err, context.Canceled) {
					log.Printf("Context canceled during fast apply validation")
					return
				}

				log.Printf("buildRace - fast apply validation failed with error: %v", err)
				sendErr(fmt.Errorf("fast apply validation failed: %w", err))
				onFail()
				return
			}

			if validateResult.valid {
				log.Printf("buildRace - fast apply validation succeeded")
				fileState.builderRun.FastApplySuccess = true
				sendRes(raceResult{content: validateResult.updated, valid: validateResult.valid})
			} else {
				log.Printf("buildRace - fast apply validation failed with problem: %s", validateResult.problem)
				fileState.builderRun.FastApplyFailureResponse = validateResult.problem
				sendErr(fmt.Errorf("fast apply validation failed: %s", validateResult.problem))
				onFail()
				return
			}
		}()
	}

View on GitHub (pinned to e2d772072e)

Solutions

  1. Check the wrapped cause with errors.Is/As on the returned error and the preceding log line 'fast apply validation failed with error'
  2. Verify LLM provider health/credentials used by the validate loop
  3. Ensure cancellation is detected with errors.Is(err, context.Canceled) so user cancels don't surface as failures
  4. Retry the build; onFail() already starts the whole-file fallback

Example fix

// before
if errors.Is(err, context.Canceled) { return }
sendErr(fmt.Errorf("fast apply validation failed: %w", err))
// after
if errors.Is(err, context.Canceled) || errors.Is(err, context.DeadlineExceeded) {
	log.Printf("validation canceled/expired, skipping")
	return
}
sendErr(fmt.Errorf("fast apply validation failed: %w", err))
Defensive patterns

Strategy: try-catch

Validate before calling

// validate preconditions before running the validation loop
if buildCtx.Err() != nil { return buildCtx.Err() }
if fastApplyRes == "" { return fmt.Errorf("empty fast apply result") }

Type guard

func isCancellation(err error) bool {
	return errors.Is(err, context.Canceled) || errors.Is(err, context.DeadlineExceeded)
}

Try / catch

validateResult, err := fileState.buildValidateLoop(buildCtx, params)
if err != nil {
	if isCancellation(err) {
		return // cancellation is not a validation failure
	}
	sendErr(fmt.Errorf("fast apply validation failed: %w", err))
	onFail()
	return
}

Prevention

When it happens

Trigger: After fast apply passes syntax checks, fileState.buildValidateLoop is called with maxAttempts:1 and returns an error that is not context.Canceled — e.g. the validation LLM call fails, times out, or an internal assertion fires.

Common situations: LLM provider outages/rate limits during validation; context deadline from an ancestor context (not plain context.Canceled, so it isn't filtered); nil state in the validate loop when invoked from the fast-apply goroutine.

Related errors


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