Skip to content

processor.Transform with StopOnError double-reports the failing item and lets the rest of the batch flow downstream unmarked #82

Description

@MasterOfBinary

On master @ 58cee73, processor/transform.go:40-46:

newData, err := p.Func(item.Data)
if err != nil {
    item.Error = err
    if p.StopOnError {
        return items, err
    }
}

The same failure is recorded twice: item.Error = err and the identical err returned as the stage error. doProcessors then emits &ProcessorError{Err: err} for the returned error (batch/batch.go:427) and a second &ProcessorError{Err: item.Error} for the same item in the final per-item scan (batch/batch.go:433) — two errors on the channel for one failure, breaking error counts for callers.

Additionally, when StopOnError aborts mid-batch, the items after the failing one are returned untransformed with Error == nil, so downstream processors (e.g. processor.Channel) emit raw, untransformed Data with no indication the stage stopped.

Suggested fix: pick one reporting path (e.g. under StopOnError return the stage error and don't also set item.Error, or mark the remaining items as skipped) and document the contract on the type; add a test pinning exactly one reported error per failure.

Relations: same territory as #79 (error-plane shape); independent of PR #66 (Filter).

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions