dgraph-io/dgraph · error

%s was not executed because no suitable resolver could be fo

Error message

%s was not executed because no suitable resolver could be found - this indicates a resolver or validation bug. Please let us know by filing an issue.

What it means

The same resolverFactoryWithErrorMsg factory also installs fallback mutation resolvers with this message. It fires when a mutation reaches the GraphQL layer but no suitable resolver was registered for it, which the code itself flags as an internal resolver/validation bug rather than an expected user-facing condition.

Source

Thrown at graphql/admin/admin.go:929

			func(m schema.Mutation) resolve.MutationResolver {
				return resolve.NewDgraphResolver(resolve.NewUpdateRewriter(), dgEx)
			}).
		WithMutationResolver("updateGroup",
			func(m schema.Mutation) resolve.MutationResolver {
				return resolve.NewDgraphResolver(NewUpdateGroupRewriter(), dgEx)
			}).
		WithMutationResolver("deleteUser",
			func(m schema.Mutation) resolve.MutationResolver {
				return resolve.NewDgraphResolver(resolve.NewDeleteRewriter(), dgEx)
			}).
		WithMutationResolver("deleteGroup",
			func(m schema.Mutation) resolve.MutationResolver {
				return resolve.NewDgraphResolver(resolve.NewDeleteRewriter(), dgEx)
			})
}

func resolverFactoryWithErrorMsg(msg string) resolve.ResolverFactory {
	errFunc := func(name string) error { return errors.Errorf(msg, name) }
	qErr :=
		resolve.QueryResolverFunc(func(ctx context.Context, query schema.Query) *resolve.Resolved {
			return &resolve.Resolved{Err: errFunc(query.ResponseName()), Field: query}
		})

	mErr := resolve.MutationResolverFunc(
		func(ctx context.Context, mutation schema.Mutation) (*resolve.Resolved, bool) {
			return &resolve.Resolved{Err: errFunc(mutation.ResponseName()), Field: mutation}, false
		})

	return resolve.NewResolverFactory(qErr, mErr)
}

func (as *adminServer) getGlobalEpoch(ns uint64) *uint64 {
	e := as.globalEpoch[ns]
	if e == nil {
		e = new(uint64)
		as.globalEpoch[ns] = e

View on GitHub (pinned to 759e242be6)

Solutions

  1. File an issue with the query/mutation text and Dgraph version, as the message requests.
  2. Re-trigger the admin schema load (re-post the schema via updateGQLSchema) to restore real resolvers.
  3. Restart the instance to rebuild servers via NewServers if resolvers stay unregistered.
Defensive patterns

Strategy: fallback

Try / catch

try { await mutation(); } catch (e) { if (String(e).includes('no suitable resolver')) { logAndReportIssue(e); /* restart or re-push schema */ await uploadSchema(sdl); } else throw e; }

Prevention

When it happens

Trigger: Executing a mutation on an endpoint whose resolver factory was built by resolverFactoryWithErrorMsg (newAdminResolverFactory/resetSchema fallback) and where validation failed to reject the field, so the no-resolver fallback resolver ran.

Common situations: Schema/resolver registration out of sync after a failed resetSchema; a bug in resolver wiring or schema validation letting an unresolvable mutation through; custom builds where adminMutationResolvers missed a mutation.

Related errors


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