Sequential validation stops early

Effect.gen and Effect.flatMap are sequential — each yield* (or each chained step) only runs after the previous one succeeds. The moment any step fails, the chain short-circuits and the rest is never evaluated.

For a control-flow pipeline that is exactly what you want; for form validation, it’s the wrong default.

1
import { Effect, Exit } from "effect"
2

3
const validate = (name: string, age: number) =>
4
  Effect.gen(function* () {
5
    const validName = yield* validateName(name)   // fails first
6
    const validAge = yield* validateAge(age)      // never runs
7
    return { name: validName, age: validAge }
8
  })
9

10
const exit = await Effect.runPromiseExit(validate("", -1))
11
// exit.cause.reasons[0].error is the FieldError for "name" — the "age" error is invisible.

If a user submits a form with three invalid fields, sequential validation shows them one error, they fix it, they submit, they see the next error, and so on. Three round-trips for one form.

The remedy is to switch from chain operators to accumulate operators — that’s what the next three beats cover.

Your turn read the test that asserts only the `name` error appears. Then run the partner test that surfaces the `age` error in isolation and confirm both fields *are* invalid — sequential is hiding one of them.

Effect.validate accumulates two effects

Effect.validate(a, b) is the pair-wise accumulator. It runs both effects regardless of which fails first, and collects all failures into an array.

The result succeeds only when both effects succeed; the error channel widens to Array<E> (or NonEmptyArray<E>, depending on the variant).

1
import { Effect } from "effect"
2

3
//      ┌─── Effect<[string, number], FieldError[], never>
4
//      ▼
5
const both = Effect.validate(validateName(name), validateAge(age))
6

7
// If both invalid:  Failure([FieldError("name"), FieldError("age")])
8
// If only name bad: Failure([FieldError("name")])
9
// If both good:     Success([name, age])

Effect.validate is right for exactly two effects whose success types you want to combine. For dynamic collections, use Effect.validate (next beat) — it’s the iterable-shaped sibling.

Your turn replace the stub with `Effect.validate(validateName(name), validateAge(age))` and confirm both `FieldError`s appear in the failure exit's error array.

Effect.validate over a collection

Effect.validate(items, fn) maps an effectful function over an iterable and collects every failure — even ones discovered after the first. Unlike Effect.forEach, it never short-circuits; unlike Effect.partition (next beat), the overall result fails if any input failed.

1
import { Effect } from "effect"
2

3
//      ┌─── Effect<string[], FieldError[], never>
4
//      ▼
5
const validateEmails = (emails: ReadonlyArray<string>) =>
6
  Effect.validate(emails, validateEmail)
7

8
// Input:  ["ok@a", "bad", "ok@b", "also-bad"]
9
// Result: Failure([FieldError("bad"), FieldError("also-bad")])

Reach for validateAll when an “all-or-nothing” outcome is the right semantics — e.g. validating a batch import where one bad row should reject the whole batch but you still want every problem surfaced to the user.

Your turn run `Effect.validate` over a mixed-validity email list and confirm the failure array contains every invalid input, not just the first.

Effect.partition — partial results are fine

Effect.partition(items, fn) is the never-fails sibling of validateAll. It returns a tuple [errors, successes] and accepts that some of each is fine.

Use it when partial results are acceptable — log ingestion, bulk email sends, anything where one bad row should not prevent the good rows from being processed.

1
import { Effect } from "effect"
2

3
//      ┌─── Effect<[FieldError[], string[]], never, never>
4
//      ▼
5
const sift = (emails: ReadonlyArray<string>) =>
6
  Effect.partition(emails, validateEmail)
7

8
// Input:  ["ok@a", "bad", "ok@b"]
9
// Result: Success([[FieldError("bad")], ["ok@a", "ok@b"]])

The E channel is never — partition cannot fail. The errors are data, not failures.

That’s the deliberate difference from validateAll: choose partition when “some failed” is an acceptable outcome and you want to proceed with the rest.

Your turn partition a mixed email list and assert *both* halves — the failure array contains the invalid inputs and the success array contains the valid ones, with no overlap and no loss.