dgraph-io/dgraph · error

Not resolving subscription because schema doesn't have any f

Error message

Not resolving subscription because schema doesn't have any fields defined for subscription operation.

What it means

The schema.Operation method rejects subscription requests when the GraphQL schema defines no fields under the Subscription root. GraphQL requires a matching root field for each operation type; without schema.Subscription there is nothing to resolve a subscription against.

Source

Thrown at graphql/schema/request.go:59

// operation, all GraphQL errors encountered are returned.
func (s *schema) Operation(req *Request) (Operation, error) {
	if req == nil || req.Query == "" {
		return nil, errors.New("no query string supplied in request")
	}

	doc, gqlErr := parser.ParseQuery(&ast.Source{Input: req.Query})
	if gqlErr != nil {
		return nil, gqlErr
	}

	listErr := validator.Validate(s.schema, doc, req.Variables)
	if len(listErr) != 0 {
		return nil, listErr
	}

	if len(doc.Operations) == 1 && doc.Operations[0].Operation == ast.Subscription &&
		s.schema.Subscription == nil {
		return nil, errors.Errorf("Not resolving subscription because schema doesn't have any " +
			"fields defined for subscription operation.")
	}

	if len(doc.Operations) > 1 && req.OperationName == "" {
		return nil, errors.Errorf("Operation name must by supplied when query has more " +
			"than 1 operation.")
	}

	op := doc.Operations.ForName(req.OperationName)
	if op == nil {
		return nil, errors.Errorf("Supplied operation name %s isn't present in the request.",
			req.OperationName)
	}

	vars, gqlErr := validator.VariableValues(s.schema, op, req.Variables)
	if gqlErr != nil {
		return nil, gqlErr
	}

View on GitHub (pinned to 759e242be6)

Solutions

  1. Add subscription fields to the GraphQL schema and regenerate the handler.
  2. Change the client to use query/mutation instead of subscription.
  3. Guard the client: check the schema for a Subscription root before opening a subscription.

Example fix

// before
subscription { newPost { id } } // schema has no subscription root
// after (until subscriptions are added)
query { posts { id } }
Defensive patterns

Strategy: validation

Validate before calling

// before subscribing, check the schema supports subscriptions
if schema.Types().ForName("Subscription") == nil {
    return errors.New("server does not support subscriptions")
}

Type guard

func supportsSubscriptions(s Schema) bool {
    return s.Types().ForName("Subscription") != nil
}

Try / catch

op, err := sch.Operation(req)
if err != nil {
    if strings.Contains(err.Error(), "Not resolving subscription") {
        // fall back to polling query or notify client subscriptions unsupported
        return fallbackToQuery(req)
    }
    return err
}

Prevention

When it happens

Trigger: Sending a request whose single operation is `subscription { ... }` while the schema was generated without any subscription fields (s.schema.Subscription == nil).

Common situations: Client tries live queries/websockets against a schema that only defines query/mutation; schema was updated to remove subscriptions but clients still subscribe.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors


AI-assisted analysis of dgraph-io/dgraph@759e242be6 (2026-09-01). Data as JSON: /api/errors/b06d7a30166d5914. Report an issue: GitHub.