Do Not Filter Traces In ZIO Name Space

[adamgfraser]

Resolves #7636.

[info] timestamp=2022-12-15T14:39:26.301869Z level=ERROR thread=#zio-fiber-0 message="" cause="Exception in thread "zio-fiber-4" java.lang.RuntimeException: bad
[info]  at Test$.badFunction(Example.scala:6)
[info]  at Test$.$anonfun$run$2(Example.scala:11)
[info]  at zio.ZIO.$anonfun$map$1(ZIO.scala:960)
[info]  at <empty>.Test.run(Example.scala:10)"

[vigoo]

This will make developing ZIO ecosystem libraries much more pleasant :)

[jdegoes]

The problem seems to be that if a defect occurs directly inside a for comprehension as a val assignment, then the last known trace occurs on a preceding line of the for comprehension, which is incorrect. Basically, "defects between flatMap".

Is that correct assessment?

[adamgfraser]

I don't think that is correct.

When an exception is thrown we already take the Throwable stack trace and combine it with the ZIO Trace, which is important independent of this if a ZIO workflow wraps a user defined function that calls several other functions one of which eventually throws an exception.

So for example this code generates the following stack trace:

[info] timestamp=2022-12-28T15:01:09.224126Z level=ERROR thread=#zio-fiber-0 message="" cause="Exception in thread "zio-fiber-4" java.lang.RuntimeException: bad
[info]  at Test$.badFunction(Example.scala:6)
[info]  at Test$.$anonfun$run$2(Example.scala:11)
[info]  at <empty>.Test.run(Example.scala:10)"

This is I think exactly what we want. The exception is thrown on line 6 in badFunction, badFunction was called in line 11 of the for comprehension, and that was called in the flatMap on line 10 of the for comprehension.

The issue here is that we currently have this logic to filter out traces in the ZIO name space. So if I take the same example as above and change import zio._ to package zio the trace will be filtered out. This PR resolves that by going back to only filtering out traces from the runtime itself.

[jdegoes]

All right, makes sense, thank you!