dapr/dapr · error

init timeout for component %s

Error message

init timeout for component %s

What it means

The inline init path wraps component initialization in a context timeout parsed from spec.initTimeout (falling back to DefaultComponentInitTimeout, 5s). runInlineInit returned nil, but the init context reports DeadlineExceeded — meaning the manager gave up silently or returned just as the deadline hit — so the processor synthesizes this explicit timeout error rather than reporting success.

Source

Thrown at pkg/runtime/processor/components.go:111

	}
	cat := p.category(comp)
	if cat == "" {
		return fmt.Errorf("incorrect type %s", comp.Spec.Type)
	}
	mgr, ok := p.inlineManagers[cat]
	if !ok {
		return fmt.Errorf("unknown component category: %q", cat)
	}
	timeout, err := time.ParseDuration(comp.Spec.InitTimeout)
	if err != nil || timeout <= 0 {
		timeout = root.DefaultComponentInitTimeout
	}
	initCtx, cancel := context.WithTimeout(ctx, timeout)
	defer cancel()

	initErr := p.runInlineInit(initCtx, comp, mgr)
	if errors.Is(initCtx.Err(), context.DeadlineExceeded) && initErr == nil {
		initErr = fmt.Errorf("init timeout for component %s", comp.LogName())
	}
	p.reportInline(ctx, comp, operatorv1.EventType_EVENT_INIT, initErr)
	// Match legacy proc.Init: return the sub-processor's wrapped error
	// directly. The "outer" rterrors.NewInit wrap is only applied on the
	// loop path (AddPendingComponent), not on the synchronous Init path.
	return initErr
}

func (p *Processor) runInlineInit(ctx context.Context, comp compapi.Component, mgr inlineManager) error {
	if err := p.compStore.AddPendingComponentForCommit(comp); err != nil {
		return err
	}
	if err := mgr.Init(p.security.WithSVIDContext(ctx), comp); err != nil {
		if derr := p.compStore.DropPendingComponent(); derr != nil {
			return errors.Join(err, derr)
		}
		return err
	}

View on GitHub (pinned to 74ad417027)

Solutions

  1. Raise spec.initTimeout in the component YAML to a duration that covers the slowest expected init (e.g. '30s' or '1m')
  2. Fix the underlying slowness: network egress, DNS resolution, credentials round-trip, or pre-provision resources so init is fast
  3. Reproduce init latency directly against the backend to pick a sane timeout rather than guessing
  4. Watch ComponentInitFailed metrics/logs after the change to confirm the timeout no longer trips

Example fix

# before
spec:
  type: state.redis
  version: v1
  # no initTimeout -> 5s default
# after
spec:
  type: state.redis
  version: v1
  initTimeout: '30s'
Defensive patterns

Strategy: validation

Validate before calling

// Pre-flight: pick initTimeout from measured backend latency + margin
const measured = await timeFirstInit(component); // direct backend probe
yaml.spec.initTimeout = `${Math.ceil((measured * 3) / 1000)}s`;

Try / catch

// Server-side: catch init event errors and distinguish timeouts
if (err.message.includes('init timeout for component')) { bumpInitTimeout(comp, '1m'); }

Prevention

When it happens

Trigger: A component whose Init blocks longer than its initTimeout (or the 5s default): statestores needing schema migration, bindings opening remote connections through slow networks, secret stores waiting on a slow KMS. Because the manager itself returned nil, only the expired context reveals the timeout.

Common situations: First-start cold connections to cloud resources (CosmosDB, AWS) exceeding 5s; initTimeout left at default in component YAML; CI or geographically distant environments with high latency; component init blocked on a DNS lookup that hangs.

Understand the failure class

Related errors

AI-assisted analysis of dapr/dapr@74ad417027 (2026-08-16). Data as JSON: /api/errors/054d1e0beb6c1579. Report an issue: GitHub.