s.error (dynamic stored step error, surfaced from view step)

Error message

s.error (dynamic stored step error, surfaced from view step)

What it means

ViewStep is a bookkeeping step representing an operation on a view resource; it performs no work in Apply but replays a stored status and error so the operation shows correctly in the UI and state. If the step carries a non-empty s.error string, Apply surfaces it verbatim as the step's failure.

Source

Thrown at pkg/resource/deploy/step.go:2611

		return false
	}
	return true
}

func (s *ViewStep) IsUntargeted() bool { return false }

func (s *ViewStep) ResultOp() display.StepOp {
	return s.resultOp
}

func (s *ViewStep) Apply() (resource.Status, StepCompleteFunc, error) {
	// ViewStep is a special step that that represents an operation for a view resource.
	// It doesn't actually do anything in Apply. It's used to flow the step through the
	// system for display in the UI and so the result of the operation is recorded
	// in the state.

	if s.error != "" {
		return s.status, nil, errors.New(s.error)
	}

	// When the view step is for a replacement, we need to ensure that the old resource is marked pending delete.
	if s.op == OpCreateReplacement && s.old != nil {
		s.old.Lock.Lock()
		s.old.Delete = true
		s.old.Lock.Unlock()
	}

	return s.status, nil, nil
}

func (s *ViewStep) Fail() {
	// Nothing to do here.
}

func (s *ViewStep) Skip() {
	// Nothing to do here.

View on GitHub (pinned to 793f7b2e16)

Solutions

Look earlier in the deployment output/logs for the original underlying error that populated this view step's error string.
Fix the root cause on the actual view/child resource (permissions, config, provider error).
Re-run the operation with --debug to see the originating step that failed.
If the error string is empty-but-set incorrectly in state, refresh the stack to reconcile.

Example fix

// before: diagnosing the view step error directly
// after: run with debug to find the root step
pulumi up --debug --logtostderr -v=9

Defensive patterns

Strategy: try-catch

Try / catch

try {
  await deploy.up();
} catch (e) {
  // ViewStep errors are propagated from the underlying operation;
  // re-run with debug and inspect the earlier root-cause error.
  console.error('view step surfaced:', e.message);
  throw e;
}

Prevention

Fix the root-cause operation error — this message is only a replay of it.
Run deployments with --debug when view-step errors appear to capture the original failure.
Keep engine and provider versions aligned to avoid view/state recording mismatches.

When it happens

Trigger: A view step was constructed with s.error set (the actual underlying operation on the view resource failed elsewhere); replaying/processing the step in Apply returns errors.New(s.error).

Common situations: Any child/view resource operation failure propagated to its view step — e.g. a failed create/update of a sub-resource surfaced during UI display or state recording; debugging this requires looking at the original underlying step error logged earlier.

Related errors

AI-assisted analysis of pulumi/pulumi@793f7b2e16 (2026-08-31). Data as JSON: /api/errors/c93237c632dc7e27. Report an issue: GitHub.