Two defects in processor/error.go (validated on master @ 58cee73; found in a deep review):
1. Zero value contradicts the documented default. The FailFraction doc says "1.0 means all items will have errors (default)" and the type doc says it "marks all incoming items with the given error" — but Process treats failFraction <= 0 as pass-through (error.go:39-42). So the obvious construction &processor.Error[int]{Err: myErr} errors nothing, and tests that use it to verify error handling pass vacuously. The package's own test betrays this: it sets FailFraction: 1.0, // Default - apply to all manually.
2. Integer quantization. failEvery := int(1.0 / failFraction) (error.go:51) truncates: 0.6 → failEvery=1 → 100% of items fail; 0.4 → 2 → exactly 50%. Only rates of the form 1/n are achievable, and the deterministic every-Nth pattern isn't "approximately half" as the doc implies.
Suggested fix: decide the semantics explicitly — either honor the documented all-fail default (requires distinguishing unset from 0.0, e.g. a constructor per #74's direction) or fix the docs to say zero = no failures; document or replace the 1/n quantization. This is a testing utility, so a breaking change is fine under the v0 policy.
Relations: surfaced while validating #74 (factories would not fix either defect); independent of PRs #65/#66.
Two defects in
processor/error.go(validated on master @ 58cee73; found in a deep review):1. Zero value contradicts the documented default. The
FailFractiondoc says "1.0 means all items will have errors (default)" and the type doc says it "marks all incoming items with the given error" — butProcesstreatsfailFraction <= 0as pass-through (error.go:39-42). So the obvious construction&processor.Error[int]{Err: myErr}errors nothing, and tests that use it to verify error handling pass vacuously. The package's own test betrays this: it setsFailFraction: 1.0, // Default - apply to allmanually.2. Integer quantization.
failEvery := int(1.0 / failFraction)(error.go:51) truncates: 0.6 → failEvery=1 → 100% of items fail; 0.4 → 2 → exactly 50%. Only rates of the form 1/n are achievable, and the deterministic every-Nth pattern isn't "approximately half" as the doc implies.Suggested fix: decide the semantics explicitly — either honor the documented all-fail default (requires distinguishing unset from 0.0, e.g. a constructor per #74's direction) or fix the docs to say zero = no failures; document or replace the 1/n quantization. This is a testing utility, so a breaking change is fine under the v0 policy.
Relations: surfaced while validating #74 (factories would not fix either defect); independent of PRs #65/#66.