What causes "failed to read input statements" in tomnomnom/gron?

Keep statement lines under the 1MiB scanner limit (split large values)

failed to read input statements

Error message

failed to read input statements

What it means

The ungron action reads input statements line by line. If bufio.Scanner returns a read error (scanner.Err() != nil) — as opposed to clean EOF — ungron returns the fixed message "failed to read input statements" with exit code exitReadInput. Notably the underlying cause is not wrapped, so the original error is lost.

Source

Thrown at main.go:359

	scanner.Buffer(make([]byte, 64*1024), 1024*1024)

	if opts&optJSON > 0 {
		maker = statementFromJSONSpec
	} else {
		maker = statementFromStringMaker
	}

	// Make a list of statements from the input
	var ss statements
	for scanner.Scan() {
		s, err := maker(scanner.Text())
		if err != nil {
			return exitParseStatements, err
		}
		ss.add(s)
	}
	if err := scanner.Err(); err != nil {
		return exitReadInput, fmt.Errorf("failed to read input statements")
	}

	// turn the statements into a single merged interface{} type
	merged, err := ss.toInterface()
	if err != nil {
		return exitParseStatements, err
	}

	// If there's only one top level key and it's "json", make that the top level thing
	mergedMap, ok := merged.(map[string]interface{})
	if ok {
		if len(mergedMap) == 1 {
			if _, exists := mergedMap["json"]; exists {
				merged = mergedMap["json"]
			}
		}
	}

View on GitHub (pinned to 88a6234ea2)

Solutions

Keep statement lines under the 1MiB scanner limit (split large values)
Re-run once the input source is stable/available
Feed ungron from a regular file or pipe with a live writer
Capture the underlying scanner error by reproducing the read in a test, since this message hides the cause

Example fix

// before
$ gron --ungron < (producer.sh)   // producer died mid-stream

// after
$ producer.sh > out.gron && gron --ungron < out.gron

Defensive patterns

Strategy: fallback

Validate before calling

fi, err := os.Stat(path)
if err != nil || !fi.Mode().IsRegular() { /* avoid unstable sources */ }

Try / catch

code, err := ungron(input, output, opts)
if err != nil {
	if err.Error() == "failed to read input statements" {
		// retry with a stable file source; note cause is hidden
	}
	return err
}

Prevention

Ungron from regular files or live pipes, not dying process substitutions
Keep statement lines under the 1MiB scanner buffer
Persist intermediate output to disk before ungron-ing

When it happens

Trigger: I/O failure while `gron --ungron` reads stdin or a file: broken pipe, medium removed, permission/IO fault, or input lines exceeding the 1MiB scanner buffer limit.

Common situations: Ungron-ing from a FIFO or process substitution whose writer died; ungron-ing a file with extremely long lines (>1MB) that trips bufio.ErrTooLong; reading from a flaky network mount.

Understand the failure class

Background: "failed to read file", EACCES, ENOENT and "could not read <path>" errors: when a program can't read a file from disk — this error's family across 49 libraries.

Related errors

AI-assisted analysis of tomnomnom/gron@88a6234ea2 (2026-09-06). Data as JSON: /api/errors/33ca071f6c949161. Report an issue: GitHub.