Current outcome
Make error classification clear and correct. errors.As rejecting a value target when the dynamic error is a pointer is normal Go behavior, not an errors.As defect.
Replanned on 2026-09-06 against GoBatch master 63ef757 and ShitQuant's recorder, enrichment, paper/replay, and flow workloads. This is an implementation target, not a claim that the behavior already exists.
Required behavior
Verification and completion
Compile and run small error-classification examples for source/stage/item categories; verify wrapping retains causes and item identity where promised.
Follow the repository's formatting, race-test, vet/lint, package documentation, example and changelog requirements for the changed surface. Report the actual supported behavior and migration; do not treat a passing coverage percentage as proof of these outcomes.
Scope and relationships
Depends on the final #79 error shape. This issue is documentation/behavioral conformance, not a broad redesign of Go error matching.
Design history
The earlier report/prototype remains below for provenance; the requirements above supersede conflicting prescriptions. Existing discussion is preserved.
Original issue: errors.As with a value target never matches SourceError/ProcessorError
The engine emits pointer errors (batch/batch.go:385,427,433):
b.errs <- &SourceError{Err: err}
b.errs <- &ProcessorError{Err: err}
but the godoc on Batch says errors "will be of type SourceError / ProcessorError" (batch/batch.go:42,82), so the natural user code
var pe batch.ProcessorError
if errors.As(err, &pe) { ... }
silently never matches — *ProcessorError is not assignable to ProcessorError. Every error classifies as "other".
Fix options (decide once, before the v1 freeze):
- Commit to pointer identity: pointer receivers on
Error/Unwrap, document the errors.As(err, &target) pointer-target form everywhere.
- Ship
IsSourceError(err) / IsProcessorError(err) helpers and steer docs to those.
PRs #65/#68 add doc clarifications only; the type-identity decision is design work that belongs with the error-plane redesign (#79, #87).
Found in the 2026-07-10 full-repo review.
Current outcome
Make error classification clear and correct. errors.As rejecting a value target when the dynamic error is a pointer is normal Go behavior, not an errors.As defect.
Replanned on 2026-09-06 against GoBatch master
63ef757and ShitQuant's recorder, enrichment, paper/replay, and flow workloads. This is an implementation target, not a claim that the behavior already exists.Required behavior
Verification and completion
Compile and run small error-classification examples for source/stage/item categories; verify wrapping retains causes and item identity where promised.
Follow the repository's formatting, race-test, vet/lint, package documentation, example and changelog requirements for the changed surface. Report the actual supported behavior and migration; do not treat a passing coverage percentage as proof of these outcomes.
Scope and relationships
Depends on the final #79 error shape. This issue is documentation/behavioral conformance, not a broad redesign of Go error matching.
Design history
The earlier report/prototype remains below for provenance; the requirements above supersede conflicting prescriptions. Existing discussion is preserved.
Original issue: errors.As with a value target never matches SourceError/ProcessorError
The engine emits pointer errors (
batch/batch.go:385,427,433):but the godoc on
Batchsays errors "will be of type SourceError / ProcessorError" (batch/batch.go:42,82), so the natural user codesilently never matches —
*ProcessorErroris not assignable toProcessorError. Every error classifies as "other".Fix options (decide once, before the v1 freeze):
Error/Unwrap, document theerrors.As(err, &target)pointer-target form everywhere.IsSourceError(err) / IsProcessorError(err)helpers and steer docs to those.PRs #65/#68 add doc clarifications only; the type-identity decision is design work that belongs with the error-plane redesign (#79, #87).
Found in the 2026-07-10 full-repo review.