apache/beam · error
source failed processing data
Error message
source failed processing data
What it means
The DataSource process() loop wraps any error returned by the user DoFn's process callback while consuming a data element. The underlying error is preserved via errors.Wrapf; io.EOF is excluded because it signals a successfully drained reader, not a failure. This means the actual failure is a user DoFn error or a nested decode/process error, surfaced at the source boundary.
Solutions
- Inspect the wrapped (cause) error in the message chain to find the failing DoFn or decoder
- Fix the user DoFn code that returned the error for the offending record
- Re-verify coder consistency between pipeline construction and runtime (same SDK versions)
- If caused by a specific element, filter or handle bad records defensively in the DoFn
Example fix
// before
func (fn *myFn) ProcessElement(v string) error {
return doSomething(v) // may fail on bad input
}
// after
func (fn *myFn) ProcessElement(v string) error {
if err := doSomething(v); err != nil {
// handle or fall back instead of failing the bundle
return handleGracefully(v, err)
}
return nil
} Defensive patterns
Strategy: try-catch
Try / catch
// DoFn process errors propagate as wrapped 'source failed processing data'
if err := dofn.ProcessElement(v); err != nil {
// log and decide: fail bundle vs. skip record
log.Errorf("element %v failed: %v", v, err)
return err // or return nil to skip
} Prevention
- Make DoFns defensive against malformed/unexpected input values
- Return nil for skip-worthy bad records instead of failing the whole bundle
- Keep coder definitions in sync across pipeline stages
- Add unit tests for DoFn edge cases
When it happens
Trigger: A data element arrives on the runner's data channel with len(e.Data)>0; r.Reset(e.Data) succeeds but the `data(&bcr, e.PtransformID)` callback (which decodes elements and invokes the DoFn) returns a non-nil error other than io.EOF.
Common situations: User DoFn panics/returns errors inside processElement; custom coders failing to decode; downstream transform raising errors on specific records; corrupted element payloads from an incompatible pipeline version.
Understand the failure class
Background: "Must be a positive integer", "Invalid value", "Unsupported": the invalid-argument-value error family, when a library rejects the value you pass — this error's family across 35 libraries.
Related errors
AI-assisted analysis of apache/beam@12126d8942 (2026-09-13).
Data as JSON: /api/errors/06594b86040fc58c.
Report an issue: GitHub.
Appendix: source
Thrown at sdks/go/pkg/beam/core/runtime/exec/datasource.go:146
var byteCount int
bcr := byteCountReader{reader: &r, count: &byteCount}
for {
n.consumingReceivedData.Store(false)
var err error
select {
case e, ok := <-elms:
n.consumingReceivedData.Store(true)
// Channel closed, so time to exit
if !ok {
return nil
}
if len(e.Data) > 0 {
r.Reset(e.Data)
err = data(&bcr, e.PtransformID)
}
if err != nil && err != io.EOF {
return errors.Wrapf(err, "source failed processing data")
}
// Process any simultaneously sent timers.
// If the data channel has split though
if len(e.Timers) > 0 {
r.Reset(e.Timers)
err = timer(&bcr, e.PtransformID, e.TimerFamilyID)
}
if err != nil && err != io.EOF {
return errors.Wrap(err, "source failed processing timers")
}
// io.EOF means the reader successfully drained.
// We're ready for a new buffer.
case <-ctx.Done():
// now that it is done processing received data, we set it to false.
n.consumingReceivedData.Store(false)
return nil
}
}View on GitHub (pinned to 12126d8942)