grafana/k6 · error

could flush the data to the output: %w

Error message

could flush the data to the output: %w

What it means

After marshaling succeeds, yamlPrint writes the bytes with fmt.Fprint to the writer (typically stdout). If the write fails — most commonly a broken pipe when the consumer closed early (e.g. piping to head) — the error is wrapped as "could flush the data to the output".

Source

Thrown at internal/cmd/ui.go:404

					termWidth = tw
				}
			}
		}
		renderProgressBars(true)
		gs.OutMutex.Lock()
		printProgressBars()
		gs.OutMutex.Unlock()
	}
}

func yamlPrint(w io.Writer, v any) error {
	data, err := yaml.Marshal(v)
	if err != nil {
		return fmt.Errorf("could not marshal YAML: %w", err)
	}
	_, err = fmt.Fprint(w, string(data))
	if err != nil {
		return fmt.Errorf("could flush the data to the output: %w", err)
	}
	return nil
}

View on GitHub (pinned to 93accf6570)

Solutions

  1. Capture to a file first, then post-process: k6 status > status.yaml && head -5 status.yaml
  2. Use a full-stream reader (less) instead of head
  3. In wrapper programs, read stdout to EOF before exiting the reader process

Example fix

# before
k6 status | head -5   # reader closes the pipe early
# after
k6 status > status.yaml && head -5 status.yaml
Defensive patterns

Strategy: fallback

Try / catch

# Write to a file so short-lived readers cannot break the pipe
k6 status > status.yaml || { echo 'stdout write failed' >&2; exit 2; }
head -5 status.yaml

Prevention

When it happens

Trigger: Piping the command's output to a short-reading consumer that exits before k6 finishes writing, e.g. 'k6 status | head -1'; stdout redirected to a closed or unlinked file descriptor.

Common situations: Shell pipelines with head/less quitting early; CI capturing output into a closed fd; terminal window closed mid-output.

Related errors


AI-assisted analysis of grafana/k6@93accf6570 (2026-08-15). Data as JSON: /api/errors/26a762dc9aedac09. Report an issue: GitHub.