StackOverflowError generating ScalaCheck Aribtrary with magnolia on Scala 3

[BusyByte]

Compiler version

compiler version: version 3.3.3

cross compiling for both 3.3.3 and 2.13.13
compiles for 2.13.13 using macro library not available in 3
trying to use magnolia and has worked on smaller examples but failing with the below on more complex examples:
trying to derive ScalaCheck Arbitraries with Scala 3
Event is basically a sealed trait and has a 105 case classes which extend it and includes case objects as well with one of 2 values in one of the events.

Minimized code

trait MagnoliaArbitrary extends Derivation[Arbitrary] {

  override def join[T](ctx: CaseClass[Arbitrary, T]): Arbitrary[T] =
    Arbitrary {
      Gen.lzy(ctx.constructMonadic(param => param.typeclass.arbitrary))
    }

  override def split[T](ctx: SealedTrait[Arbitrary, T]): Arbitrary[T] = {
    Arbitrary {
      Gen.oneOf(ctx.subtypes.map(_.typeclass.arbitrary)).flatMap(identity)
    }
  }

  implicit private val monadicGen: Monadic[Gen] = new Monadic[Gen] {
    override def point[A](value: A): Gen[A] = Gen.const(value)

    override def flatMap[A, B](from: Gen[A])(fn: A => Gen[B]): Gen[B] = from.flatMap(fn)

    override def map[A, B](from: Gen[A])(fn: A => B): Gen[B] = from.map(fn)
  }

// in ArbitraryInstances object extending MagnoliaArbitrary
// ... it made me add types for all the types needed for event so there are 61 lines of this since it's semi-auto derivation
implicit val arbEvent: Arbitrary[Event] = derived

Output (click arrow to expand)

[info] compiling 8 Scala sources to /omitted/target/scala-3.3.3/test-classes ...

  unhandled exception while running inlining on /omittted/src/test/scala/com/deere/mycopackage/scalacheck/ArbitraryInstances.scala

  An unhandled exception was thrown in the compiler.
  Please file a crash report here:
  https://github.com/lampepfl/dotty/issues/new/choose

     while compiling: /omitted/src/test/scala/com/mycopackage/scalacheck/ArbitraryInstances.scala
        during phase: inlining
                mode: Mode(ImplicitsEnabled)
     library version: version 2.13.12
    compiler version: version 3.3.3
            settings: -Werror true -Wnonunit-statement true -Wunused List(implicits, explicits, imports, locals, params, privates) -Wvalue-discard true -Xmax-inlines 100 -Xplugin List(target/scala-3.3.3/compiler_plugins/wartremover_3.3.3-3.1.6.jar) -Ykind-projector "" -bootclasspath /Users/omitted/target/scala-3.3.3/test-classes -deprecation true -encoding utf8 -feature true -java-output-version 9 -language List(experimental.macros, higherKinds, implicitConversions)

[error] ## Exception when compiling 8 sources to /omitted/target/scala-3.3.3/test-classes
[error] java.lang.StackOverflowError

[BusyByte]

After looking at this more since i have 105 that extend event but only 61 lines defining them with derived it made me add I think am running into softwaremill/magnolia#464

Just strange that it made me add some but not all and then it recurses on itself.
I'm going to work on adding the missing and see if that helps

[BusyByte]

Now I'm getting a different problem now I added them all:

[error] Error while emitting com/mycopackage/scalacheck/ArbitraryInstances$
[error] Method too large: com/mycopackage/scalacheck/ArbitraryInstances$.<clinit> ()V

[BusyByte]

Yeah, still haven't found a solution, I moved the arbitraries to different objects and also tried auto-derivation.
It still is giving StackOverflowError

[BusyByte]

I tried to use https://github.com/martinhh/scalacheck-derived as well but it is giving me StackOverflowError as well.

[SethTisue]

Does giving the compiler more stack make the problem go away? See discussion starting at #20152 (comment)

[BusyByte]

@SethTisue yes, this fixed the issue. Thank you very much!

[BusyByte]

@SethTisue it's still a bit strange I have to autoDerive more than just the event, I ended up having to autoDerive 27 other case classes and one for cats NEL which is expected. Seems like the autoDerive of the case classes could be done for me automatically if this were truly auto but this seems like a happy compromise to me to get things working. I also have a slightly different implementation than I started with which we had previously been using. I might try a different implementation out and see if it makes a difference but I have something workable which makes me happy.

[SethTisue]

sounds like something you could potentially take up with the users and/or maintainers of the libraries in question