[ybai08]

Intersecting a length bound with a range that it narrows to a single length throws an internal error:

type("1 <= string <= 2").and("string >= 2")
// Error: Unexpectedly encountered multiple distinct intersection results for refinement Type<>= 2>

The same thing happens for arrays (type("string[] <= 2").and("string[] >= 1").and("string[] >= 2")). The number and Date equivalents already work (type("1 <= number <= 2").and("number >= 2") is 2).

In intersectConstraints, the new >= 2 reduces with both existing bounds: with <= 2 to == 2 and with >= 1 to >= 2. For numbers and dates, the first result is a unit, which takes the isRoot() path, but for lengths it's an exactLength constraint, so the loop reached the "multiple distinct intersection results" branch. That branch now replaces the second constraint with its result and queues that result to be intersected with the rest (here == 2 & >= 2, which is == 2). It always shrinks l by one, so it terminates, and it only runs where the code used to throw.

This also blocks .out on a tuple with a default after a prefix element, e.g. type(["number", "string = 'foo'"]).out, since the output's implied length of 2 is reduced against the original minLength: 1 / maxLength: 2. That case also needs the separate tuple reduceIo fix in #1696. With both, it gives [number, string].

Tests

• ark/schema/__tests__/bounds.test.ts: "unit range reduces when narrowing an existing range" for each of min/max, minLength/maxLength and after/before, in both operand orders
• ark/type/__tests__/range.test.ts: "== length from narrowing a length range" for strings and arrays

On main these fail for lengths only (numbers and dates already pass). With this change they all pass.

What was run locally:

• pnpm testFiles ark/type/__tests__/range.test.ts ark/schema/__tests__/bounds.test.ts (with type assertions): 86 passing
• pnpm test: 1795 passing
• pnpm typecheckRepo: no errors
• prettier --check and eslint on the changed files: clean

Not run: the full pnpm prChecks (buildRepo, benches, testV8, testIntegration, testTsVersions, testTypedLoose). I didn't run the benchmarks because the change only touches the branch that used to throw.

[pullfrog]

Important

The core reduction fix is correct and well-tested, but removing the throwInternalError guard means type(["number", "string = 'foo'"]).out now silently returns an incorrect type instead of throwing. That is only correct once the paired #1696 lands, so please land them together (or keep a guard until then).

Reviewed changes

This run reviewed the single commit on fix/length-bound-intersection (3 files).

• intersectConstraints multi-reduction — ark/schema/constraint.ts: when head reduces a second existing constraint to a distinct result, the branch now splices that constraint out and queues its result to be intersected with the rest, instead of throwing.
• bounds tests — ark/schema/__tests__/bounds.test.ts: new "unit range reduces when narrowing an existing range" case for min/max, minLength/maxLength, and after/before, in both operand orders.
• range tests — ark/type/__tests__/range.test.ts: new "== length from narrowing a length range" covering strings (expression/allows) and arrays (json).

The reduction logic itself checks out: pnpm test is 1795 passing, and exhaustive/randomized probing over all bound kinds found no input where the reduced node differs from the full conjunction or fails to terminate.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using deepseek-v4.1-flash (free via Pullfrog for OSS) ｜ 𝕏}

[pullfrog]

Removing this guard changes type(["number", "string = 'foo'"]).out from a thrown internal error into a silently incorrect type: it now yields [number], so out.allows([1, "foo"]) is false and out.allows([1]) is true. The intersection result here is only correct for the already-corrupted .out structure, which the paired #1696 fixes. Please land #1696 in the same release (or keep a guard / pin .out to [number, string] in a test) so this PR alone doesn't ship a wrong output type.

Technical details

# Removed guard lets an incorrect tuple `.out` ship

## Affected sites
- `ark/schema/constraint.ts:205-210` — the `throwInternalError` is replaced by a splice/requeue, so the previously-throwing `.out` path now returns a result
- `ark/schema/structure/sequence.ts:135-143` — `defaultables.reduceIo` assigns over `inner.prefix` on `out` instead of combining, dropping the surrounding prefix (this is the root cause, tracked by #1696)

## Evidence
```ts
type(["number", "string = 'foo'"]).out
// head: json {"sequence":{"prefix":["number"]},"proto":"Array","exactLength":1}
//       out.allows([1, "foo"]) === false, out.allows([1]) === true
// base (constraint.ts reverted): throws
//       "Unexpectedly encountered multiple distinct intersection results for refinement Type<<= 1>"
```
Control: `type(["number", "string"]).out` is `[number, string]` (exactLength 2).

## Required outcome
- The removed guard must not ship on its own, since it converts a loud internal error into a silently wrong public output type. Landing #1696 in the same release (or adding a guard/test that pins `.out` to `[number, string]`) resolves this.

## Open questions for the human
- Is #1696 expected to merge before/with this PR, or should the guard stay until then?

[ssalbdivad]

thanks @ybai08! landed this together with #1696 since the tuple .out case needs both. kept your tests and tweaked the fix slightly so type("1 <= string <= 3").and("string == 2") also reduces all the way to string == 2