Internal Server Error - a panic was trapped. This indicates

Error message

Internal Server Error - a panic was trapped.  This indicates a bug in the GraphQL server.  A stack trace was logged.  Please let us know by filing an issue with the stack trace.

What it means

This is Dgraph's GraphQL panic-recovery message. The `PanicHandler` wrapper runs `recover()` around GraphQL resolution; when the server code panics, it logs the panic with a stack trace via glog and replaces the real error with this generic internal-server-error string so internals never leak to clients.

Source

Thrown at graphql/api/panics.go:25

import (
	"runtime/debug"

	"github.com/golang/glog"
	"github.com/pkg/errors"
)

// PanicHandler catches panics to make sure that we recover from panics during
// GraphQL request execution and return an appropriate error.
//
// If PanicHandler recovers from a panic, it logs a stack trace, creates an error
// and applies fn to the error.
func PanicHandler(fn func(error), query string) {
	if err := recover(); err != nil {
		// Log the panic along with query which caused it.
		glog.Errorf("panic: %s.\n query: %s\n trace: %s", err, query, string(debug.Stack()))

		fn(errors.Errorf("Internal Server Error - a panic was trapped.  " +
			"This indicates a bug in the GraphQL server.  A stack trace was logged.  " +
			"Please let us know by filing an issue with the stack trace."))
	}
}

View on GitHub (pinned to 759e242be6)

Solutions

Check the Dgraph server logs for the `panic:` entry with the stack trace — it names the real failing function and reason
File an issue at github.com/dgraph-io/dgraph with the stack trace and the query that triggered it, as the message instructs
Reproduce with the logged query to identify the input (variable values, schema feature) that triggers the panic
Upgrade to the latest Dgraph release, since panics are usually fixed as bugs

Defensive patterns

Strategy: try-catch

Try / catch

try {
  const res = await fetch('/admin/graphql', {method:'POST', body: JSON.stringify({query})});
  const body = await res.json();
  if (body.errors?.some(e => e.message.includes('panic was trapped'))) {
    console.error('Server bug; check Dgraph server logs for stack trace and file an issue');
  }
} catch (err) { /* network failure path */ }

Prevention

Keep Dgraph upgraded to the latest patch release
Include the failing query and stack trace from server logs when reporting
Avoid exotic schema edge cases until a fix is released

When it happens

Trigger: Any GraphQL resolver that panics — nil pointer dereference, index out of range, type assertion failure — during query/mutation execution. The panic is caught in PanicHandler (called from the Resolve path), the stack trace is written to the server log, and the client gets this message.

Common situations: Malformed or deeply nested queries that hit edge cases in resolver code; bugs in custom lambda resolvers; schema/data conditions the server didn't anticipate; concurrent requests racing on shared state.

Understand the failure class

HTTP status errors: handling 4xx and 5xx responses — how to handle 4xx and 5xx responses properly.

Related errors

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