dgraph-io/dgraph · error

Query couldn't be executed

Error message

Query couldn't be executed

What it means

During ExecutionResult processing, Dgraph tracks per-subgraph execution in a hasExecuted bitmap. If any subgraph never executed (e.g. its processing path returned early or was skipped), the whole query returns this error. It signals an internal scheduling/processing failure rather than a data problem.

Source

Thrown at query/query.go:3025

					start, end := x.PageRange(sg.Params.Cascade.First,
						sg.Params.Cascade.Offset, len(sg.uidMatrix[i].Uids))
					sg.uidMatrix[i].Uids = sg.uidMatrix[i].Uids[start:end]
				}
			}
			spana.End()

			_, spanp := otel.Tracer("").Start(ctx, "Populate Post Aggregation Var Map "+sg.Attr)
			if err := sg.populatePostAggregation(req.Vars, []*SubGraph{}, nil); err != nil {
				return err
			}
			spanp.End()
		}
	}

	// Ensure all the queries are executed.
	for _, it := range hasExecuted {
		if !it {
			return errors.Errorf("Query couldn't be executed")
		}
	}
	req.Latency.Processing += time.Since(execStart)

	// If we had a shortestPath SG, append it to the result.
	if len(shortestSg) != 0 {
		req.Subgraphs = append(req.Subgraphs, shortestSg...)
	}
	return nil
}

// ExecutionResult holds the result of running a query.
type ExecutionResult struct {
	Subgraphs  []*SubGraph
	SchemaNode []*pb.SchemaNode
	Types      []*pb.TypeUpdate
	Metrics    map[string]uint64
}

View on GitHub (pinned to 759e242be6)

Solutions

  1. Retry the query once to rule out a transient internal scheduling issue
  2. Split the query into separate simpler requests (run recurse/shortest blocks separately)
  3. Check server logs for a preceding root-cause error in the same request
  4. Upgrade Dgraph; this guard usually indicates an internal bug fixed in later versions
Defensive patterns

Strategy: retry

Try / catch

var resp *api.Response
for i := 0; i < 2; i++ {
    resp, err = txn.Query(ctx, dql)
    if err == nil || !strings.Contains(err.Error(), "Query couldn't be executed") {
        break
    }
    // split complex query into simpler blocks before retry
}

Prevention

When it happens

Trigger: Executing a multi-block or recursion/shortest-path query where one of the subgraphs is not marked executed in the hasExecuted slice, typically due to an internal skip path in processTaskPartial or query planning.

Common situations: Complex queries combining recurse/shortest-path blocks with other blocks, intermittent internal failures, or queries whose subgraph list length mismatched expected execution count.

Related errors


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