dapr/dapr · error

binding %s does not support operation %s. supported operatio

Error message

binding %s does not support operation %s. supported operations:%s

What it means

Thrown by SendToOutputBinding in the Dapr runtime when an invoke request targets an output binding that exists but whose component does not implement the requested operation. Each output binding component declares its capabilities via the bindings.Operations() method, and the runtime only calls binding.Invoke when slices.Contains(ops, req.Operation) matches. The error message helpfully lists every operation the component actually supports.

Source

Thrown at pkg/runtime/processor/binding/send.go:218

	if binding, ok := b.compStore.GetOutputBinding(name); ok {
		ops := binding.Operations()
		if slices.Contains(ops, req.Operation) {
			policyRunner := resiliency.NewRunner[*bindings.InvokeResponse](ctx,
				b.resiliency.ComponentOutboundPolicy(name, resiliency.Binding),
			)

			return policyRunner(func(ctx context.Context) (*bindings.InvokeResponse, error) {
				return binding.Invoke(ctx, req)
			})
		}

		supported := make([]string, 0, len(ops))
		for _, o := range ops {
			supported = append(supported, string(o))
		}

		return nil, fmt.Errorf("binding %s does not support operation %s. supported operations:%s", name, req.Operation, strings.Join(supported, " "))
	}

	return nil, fmt.Errorf("couldn't find output binding %s", name)
}

func (b *binding) onAppResponse(ctx context.Context, response *bindings.AppResponse) error {
	if len(response.State) > 0 {
		b.wg.Add(1)

		go func(reqs []state.SetRequest) {
			defer b.wg.Done()

			store, ok := b.compStore.GetStateStore(response.StoreName)
			if !ok {
				return
			}

			err := stateLoader.PerformBulkStoreOperation(ctx, reqs,

View on GitHub (pinned to 74ad417027)

Solutions

  1. Change the request's operation to one listed in the error message's 'supported operations:' section (most bindings only support 'create')
  2. Check the binding component's source or docs for its Operations() implementation to know what is allowed before coding
  3. If you need get/delete/exec semantics, use the state store, secret, or service invocation API instead of an output binding

Example fix

// before (Kafka output binding)
curl -X POST http://localhost:3500/v1.0/bindings/my-kafka -d '{"operation": "get", "data": {...}}'
// after
 curl -X POST http://localhost:3500/v1.0/bindings/my-kafka -d '{"operation": "create", "data": {...}}'
Defensive patterns

Strategy: validation

Validate before calling

// Before invoking, check the operation is supported
const SUPPORTED = ['create']; // from the error message / component docs
if (!SUPPORTED.includes(op)) throw new Error(`unsupported op ${op}`);
await dapr.binding.send('my-binding', op, data);

Type guard

const isBindingOperation = (op) => ['create','get','delete','exec'].includes(op);

Try / catch

try { await dapr.binding.send(name, 'create', data); } catch (e) { if (e.message.includes('does not support operation')) { /* pick op from 'supported operations:' in message */ } else throw e; }

Prevention

When it happens

Trigger: Calling the output bindings API POST /v1.0/bindings/{name} with an 'operation' field the component does not export (e.g. 'get' or 'delete' on a Kafka binding that only implements 'create'), or an AppResponse from an input-binding handler with a 'to' destination whose binding cannot perform the implicitly used create operation.

Common situations: Assuming all bindings behave like storage bindings and supporting create/get/delete/exec; switching a binding component (e.g. redis -> kafka) without updating the operation field in app code; copying YAML examples that use operations valid only for a different binding type.

Related errors


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