Stack overflow error when attempting to trace deeply nested object

[rohan-datar]

I'm working on creating a minimal reproduction of this, but when trying to trace an object that is deeply nested or uses many imports, trace will throw a stack overflow error. The basic context is that I am attempting to write some tests that run sanity checks on configuration written in pkl. The configuration amends a template that is defined in a remote module and is declared as a dependency is the PklProject file. The template itself imports a number of other modules that define type constraints and some output converters.

The test imports the configuration and defines some fact tests to check the sanity of the configuration. I am using import statements so that I can set some environment values that are otherwise provided at evaluation time. I wanted to trace the amended value to make sure that the values were being set correctly and ran into this error. The interesting thing is that the value can be operated on fine. Running comparisons for the facts works fine even for deeply nested values, but attempting to trace or render the same value produces a stack overflow error.

The error is too long to paste directly so I'm attaching it as a file:
trace_stack_overflow.txt

[HT154]

Without a repro to look at, my suspicion is there's a circular data reference somewhere in the value. This is valid in Pkl as long as you don't attempt to render the value (including via trace). Your comparisons may not be exercising the specific cycle.

One thing to note: Pkl's stack overflow reporting is heuristic. It tries to determine (from a Java stacktrace) if the overflow happened within Pkl code. When it detects this, you'll get a helpful error showing the cycle in Pkl, but in some cases it may fail to identify the cycle and produce the less helpful Java stack trace like you see here.

[rohan-datar]

Could this be caused by an import cycle? I'm fairly certain there is one in the module I'm importing, which would explain it. I see #1183 but I've never run into a NullPointerException and afaik there's nothing in pkl itself that disallows circular imports.