[dinwwwh]

Requested by dinwwwh · project thread

Problem

downgradeV30 in src/v3.1-to-v3.0.ts keeps two module-level lists, twoBranchAnyOfs and anyOfTargets, for the nullable merge. They were cleared at the start of a call and at its successful end, but not when conversion threw (for example the RangeError on very deep nesting that the README lists). Until the next call, they kept the input and the partial output alive: on a 50k-schema doc, about 61.7 MB stayed retained after a throw versus 4.2 MB after a success.

Fix

Wrap the body in try/finally and clear both lists once, in finally. Since every call now ends with them empty, the clear at the start is dropped. The loop iterates twoBranchAnyOfs directly instead of splice(0), because mergeNullable never pushes to it.

Checks

• pnpm test: 262 tests pass; pnpm run check clean.
• Output byte-identical to main on 80 real 3.1 documents.
• Checked by hand that a call after a deep-nesting RangeError still merges anyOf: [string, null] into nullable: true. No gc-based unit test, since that would be flaky.

---

Generated by Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[codspeed]

Merging this PR will not alter performance

✅ 21 untouched benchmarks

---

_{Comparing claude/project-thread-fpuvkk (167541a) with main (6a906e9)}

[pullfrog]

✅ No new issues found.

Reviewed changes

• Wrap downgradeV30 in try/finally — clears twoBranchAnyOfs and anyOfTargets even when conversion throws, so a failed call no longer retains the input and partial output until the next call.
• Drop the start-of-call clear — now redundant since every call ends with both lists empty.
• Iterate twoBranchAnyOfs directly instead of splice(0) — valid because mergeNullable never pushes to the list.

The direct iteration is safe: mergeNullable only calls isOnlyNullSchema, isRecord, getRef, find, rejectsNull, and Object.assign, none of which re-enter conversion. downgradeV30 is also not re-entrant — the chained 3.2→3.1→3.0 path calls the two downgraders sequentially — so removing the defensive start-of-call clear cannot leak state between calls.

I confirmed the fix empirically with a throwaway probe (200k two-branch-anyOf schemas plus a >1000-deep schema to force the documented RangeError): the base retains ~142 MB after the throw, while this branch retains ~0 MB. A successful call retains ~0 MB on both. pnpm test passes (262 tests).

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