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
- Retry the query once to rule out a transient internal scheduling issue
- Split the query into separate simpler requests (run recurse/shortest blocks separately)
- Check server logs for a preceding root-cause error in the same request
- 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
- Avoid mixing recurse/shortest blocks with many other blocks in one request
- Monitor server logs for internal errors correlated with this guard
- Keep Dgraph version current; internal scheduling bugs get fixed upstream
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
- Invalid Math expression
- Invalid math statement. Expected 1 operands
- Division by zero
- Invalid Math expression. Expected 3 operands
- Invalid Math expression. Expected 2 operands
AI-assisted analysis of dgraph-io/dgraph@759e242be6 (2026-09-01).
Data as JSON: /api/errors/633154c7d5fa451e.
Report an issue: GitHub.