fix(v4): reject tuple holes before required defaults - #5900

TL;DR — Fixes tuple parsing to reject absent optional-output slots when a later slot has required output (e.g. .default()), rather than incorrectly truncating the result and silently dropping required elements.

Key changes

• Separate optin / optout start indices via getTupleOptStart helper — Replaces the single reverse-findIndex with a shared helper that computes the first required index for either dimension, clarifying the distinction between input-length validation and output-shaping.
• Gate truncation on optoutStart instead of per-element isOptionalOut — The truncation branch now fires only when the absent slot is at or past optoutStart, ensuring slots before a required-output tail (e.g. .default()) surface validation errors instead of silently trimming.
• Add regression tests for exactOptional() before .default() — Covers sync, async, and mixed optional/default tuple scenarios including the new exactOptional + default combination.

_{Summary ｜ 2 files ｜ 4 commits ｜ base: main ← fix/tuple-exact-optional-default}

Reject tuple holes that precede required output

Before: An absent optional-output slot always triggered truncation—even when a later slot had required output (e.g. .default("d")). This silently produced a shorter tuple that violated the declared output type.
After: Truncation is only applied when the absent slot is at or past the optoutStart index—the first position from which the entire remaining tail has optional output. Otherwise the absence surfaces as a validation error at the correct path index.

The fix introduces a getTupleOptStart(items, key) helper that computes the boundary for both "optin" (used by the too_small precheck) and "optout" (used by the truncation logic). The handleTupleResults function now receives optoutStart and checks i >= optoutStart rather than inspecting isOptionalOut per-element, which correctly prevents truncation when any later slot would produce required output.

Why is the per-element check insufficient?

The old code checked whether the current slot itself had optional output. But truncation drops all later slots too—including ones with required output like `.default()`. The positional `optoutStart` boundary captures the correct invariant: truncation is safe only when nothing after the current index requires materialization.

packages/zod/src/v4/core/schemas.ts · packages/zod/src/v4/classic/tests/tuple.test.ts

  ^{｜ View workflow run ｜ via Pullfrog ｜ Using Claude Opus ｜ 𝕏}

Landed in Zod 4.4