fix: make DynamicValue#toTyped stack safe using trampolining (#422)

[987Nabil]

Summary

Fixes #422

DynamicValue#toTyped uses direct recursion which causes StackOverflowError on deeply nested structures. This PR makes it stack-safe using scala.util.control.TailCalls (trampolining).

Changes

• Converted toTypedValueLazyError from direct recursion to a trampoline-based toTypedValueTrampoline method
• Converted decodeStructure to use trampoline via decodeStructureTrampoline
• Every recursive call now uses tailcall() instead of direct recursion
• Collection processing (Sequence, Set, Dictionary) uses iterative loop helpers within the trampoline
• Un-ignored the existing "toTyped is stack safe" test (was @@ TestAspect.ignore since Use CaseClass0 for representing schema of case objects #421)
• No changes to the public API

Test Results

• 539 tests pass, 0 failures
• The previously-ignored stack safety test now passes

[Copilot]

Pull request overview

Updates DynamicValue#toTyped decoding to be stack-safe for deeply nested values by replacing direct recursion with trampolined evaluation (scala.util.control.TailCalls), and re-enables the previously ignored stack-safety test from #421/#422.

Changes:

• Replaced recursive toTypedValueLazyError logic with a trampoline-based implementation (toTypedValueTrampoline).
• Updated decodeStructure to use a trampolined loop (decodeStructureTrampoline) to avoid recursive calls.
• Un-ignored and adjusted the "toTyped is stack safe" property test.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
zio-schema/shared/src/main/scala/zio/schema/DynamicValue.scala	Migrates toTyped/record decoding recursion to TailCalls trampolining for stack safety.
tests/shared/src/test/scala/zio/schema/DynamicValueSpec.scala	Re-enables the stack-safety test for toTyped with deeper generated JSON.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The new trampoline-based collection loops rely on asInstanceOf[TailRec[Either[DecodeError, t]]] casts. These casts are unsafe and can mask real type issues at compile time; it should be possible to avoid them by introducing a properly-typed helper (e.g., a local def decodeElem(e: DynamicValue): TailRec[Either[DecodeError, t]]) or by adding an explicit type parameter when calling toTypedValueTrampoline so the compiler can infer A = t without casting.

[987Nabil]

Fixed — replaced the asInstanceOf cast with an explicit type parameter: toTypedValueTrampoline[t](head, schema.elementSchema). The compiler infers the correct existential type when given the explicit parameter.

[Copilot]

This asInstanceOf[TailRec[Either[DecodeError, t]]] cast in the Set decoding loop is unsafe. Consider refactoring to a typed helper or explicitly parameterizing toTypedValueTrampoline so the element schema type is preserved without casts.

[987Nabil]

Fixed — same approach as above: explicit type parameter [t] on toTypedValueTrampoline.

[Copilot]

This dictionary decoding loop uses asInstanceOf[TailRec[Either[DecodeError, k]]] / asInstanceOf[TailRec[Either[DecodeError, v]]] casts. Since these casts bypass the type checker, it would be safer/clearer to introduce typed helper methods or explicit type parameters to toTypedValueTrampoline to avoid asInstanceOf.

[987Nabil]

Fixed — both key and value casts replaced with explicit type parameters: toTypedValueTrampoline[k](dk, schema.keySchema) and toTypedValueTrampoline[v](dv, schema.valueSchema).

[Copilot]

The test now throws an AssertionError manually and then returns assertCompletes. Using ZIO Test assertions (e.g., assert(result)(equalTo(Right(json))) / assertTrue(result == Right(json))) will produce better failure reporting and avoids relying on exceptions for control flow.

[987Nabil]

Intentionally kept as-is. Using assertTrue(result == Right(json)) causes ZIO Test's PrettyPrint to recursively pretty-print the deeply nested JSON structure on failure, which itself triggers a StackOverflowError (the PrettyPrint is not stack-safe for deeply recursive data types). The throw AssertionError + assertCompletes pattern is a workaround for this ZIO Test limitation.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Schema.Record construction uses Chunk.fromIterable(m.values), which depends on the iteration order of m (ultimately the insertion order of values) matching s.fields order. Schema.Record.construct indexes the chunk positionally, so out-of-order ListMap keys can silently swap same-typed fields or cause spurious "invalid type in values" failures. Build the Chunk[Any] in s.fields order (by field name) instead of relying on m.values ordering, or change decodeStructureTrampoline to traverse structure in order and accumulate accordingly.

Suggested change

	val constructed = s.construct(Chunk.fromIterable(m.values))(Unsafe.unsafe)
	done(constructed.left.map(err => DecodeError.MalformedField(s, err)))
	// Build the chunk in schema field order to avoid relying on ListMap insertion order.
	val fieldValuesEither: Either[DecodeError, Chunk[Any]] =
	s.fields.foldLeft[Either[DecodeError, Chunk[Any]]](Right(Chunk.empty)) { (accEither, field) =>
	accEither match {
	case Left(e) => Left(e)
	case Right(accChunk) =>
	m.get(field.name) match {
	case Some(v) => Right(accChunk :+ v)
	case None => Left(DecodeError.IncompatibleShape(values, s.fields))
	}
	}
	}
	fieldValuesEither match {
	case Left(err) =>
	done(Left(err))
	case Right(fieldValues) =>
	val constructed = s.construct(fieldValues)(Unsafe.unsafe)
	done(constructed.left.map(err => DecodeError.MalformedField(s, err)))
	}

[Copilot]

decodeStructureTrampoline does a linear structure.find(_.name == key) for every key, yielding O(n²) behavior for wide records. Since this method is on the decoding hot path, consider pre-indexing structure into a Map[String, Field[_, _]] once (or iterating structure and looking up values) to make lookups O(1) and reduce allocations.