dgraph-io/dgraph · error

line %d column %d:

Error message

line %d column %d: 

What it means

Item.Errorf is a formatting helper on the lexer's Item type in Dgraph's query lexer. It is not an error itself but the mechanism by which every lexer/parser error message gets its 'line %d column %d: ' prefix, pinpointing where in the query input the problem occurred. You see this prefix whenever any lexing or parsing error is reported.

Source

Thrown at lex/lexer.go:44

	ItemEOF ItemType = iota
	// ItemError is emitted when there was an error lexing the input.
	ItemError
)

// StateFn represents the state of the scanner as a function that returns the next state.
type StateFn func(*Lexer) StateFn

// Item represents a unit emitted by the lexer.
type Item struct {
	Typ    ItemType
	Val    string
	line   int
	column int
}

// Errorf returns an error message that includes the line and column where the error occurred.
func (i Item) Errorf(format string, args ...interface{}) error {
	return errors.Errorf("line %d column %d: "+format,
		append([]interface{}{i.line, i.column}, args...)...)
}

func (i Item) String() string {
	if i.Typ == ItemEOF {
		return "EOF"
	}
	return fmt.Sprintf("lex.Item [%v] %q at %d:%d", i.Typ, i.Val, i.line, i.column)
}

// ItemIterator iterates over the items emitted by a lexer.
type ItemIterator struct {
	l   *Lexer
	idx int
}

// NewIterator returns a new ItemIterator instance that uses the lexer.
func (l *Lexer) NewIterator() *ItemIterator {

View on GitHub (pinned to 759e242be6)

Solutions

1. Read the line/column offset in the message and fix the query text at that exact position
2. Print or log the full query being sent to verify no client-side escaping mangling occurred
3. Test the failing query in Ratel to get visual error highlighting
4. If line/column are -1 or nonsense, the iterator was used past EOF; re-validate the query with Lexer.ValidateResult before parsing

Example fix

// before (mangled multiline query string)
q := "upsert { query { q(func: eq(email, \"a@b.com\")) } mutation { set { uid <email> \"c@d.com\" . } }"
// after (balanced braces, valid DQL)
q := `upsert { query { q(func: eq(email, "a@b.com")) } mutation { set { uid <email> "c@d.com" . } } }`

// Before sending, sanity-check the DQL string
func validateQuery(q string) error {
    l := lex.NewLexer(q)
    return l.ValidateResult() // surfaces lexer errors with line/column before parse
}

err := runQuery(q)
if err != nil && strings.Contains(err.Error(), "line ") {
    // lexer-reported position; extract and show user the offending line
    return fmt.Errorf("query syntax error: %w", err)
}

When it happens

Trigger: Any call to Item.Errorf or ItemIterator.Errorf with a format string, e.g. when the GraphQL+-/DQL parser reports a syntax error; the prefix is prepended to the underlying message with the item's recorded line and column.

Common situations: Developers see 'line 1 column 12: Unexpected ...' when a DQL query sent to Dgraph via HTTP /query or gRPC Query is malformed: unbalanced braces, stray characters, bad arguments in an upsert block, or copy-pasted text with hidden characters.

Related errors

• item.Val
• while converting to subgraph
• Invalid Math expression
• Invalid math statement. Expected 1 operands
• Division by zero

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