Hello @WesselVS
Are there plans to integrate the just merged improved tracing from monix?
Yes, I've planned to do this after releasing stack traces for Monix that I want to do within a few days
Also, if I were to take a shot at this myself, what would be a good approach?
It would require copying relevant changes from this PR: https://github.com/monix/monix/pull/1267/filesmonix-bio
depends on monix-execution
so RingBuffer
will be available but the rest needs to be duplicated.
The structure is very similar so integration should be a straightforward but manual task.
Is bio forked from monix, so that I can pull in the master branch from monix into bio?
It's not a fork but it depends on some modules
If you'd like to help out then that would be fantastic
monix-bio
release a lot :)
Thanks! Just out of curiosity: I'm seeing this in the monix trace (in the test captures bracket frames
of FullStackTracingSuite
):
TaskTrace: 13 frames captured
├ apply @ tracing.FullStackTracingSuite$.new (FullStackTracingSuite.scala:117)
├ apply @ tracing.FullStackTracingSuite$.new (FullStackTracingSuite.scala:117)
├ runToFuture @ tracing.FullStackTracingSuite$.new (FullStackTracingSuite.scala:130)
├ <clinit> @ tracing.FullStackTracingSuite$.new (FullStackTracingSuite.scala:117)
├ runToFuture @ tracing.FullStackTracingSuite$.new (FullStackTracingSuite.scala:130)
├ pure @ tracing.FullStackTracingSuite$.new (FullStackTracingSuite.scala:117)
├ runToFuture @ tracing.FullStackTracingSuite$.new (FullStackTracingSuite.scala:130)
├ <clinit> @ tracing.FullStackTracingSuite$.new (FullStackTracingSuite.scala:117)
├ bracket @ tracing.FullStackTracingSuite$.new (FullStackTracingSuite.scala:117)
├ flatMap @ tracing.FullStackTracingSuite$.new (FullStackTracingSuite.scala:117)
├ flatMap @ tracing.FullStackTracingSuite$.new (FullStackTracingSuite.scala:117)
├ flatMap @ tracing.FullStackTracingSuite$.traced (FullStackTracingSuite.scala:12)
╰ map @ tracing.FullStackTracingSuite$.new (FullStackTracingSuite.scala:120)
Why is runToFuture there 3 times? The trace I'm getting in monix-bio lists the runToFuture only 2 times, but I'm trying to figure out why it's there more than once.
1.1.0
with stack traces :) https://github.com/monix/monix-bio/releases/tag/v1.1.0Future[Either[SomeFailure, A]]
for many of its operations. I would like transform that into an IO[SomeFailure, A]
and work with it until I have to actually serve the data (then runToFuture
). I assume whatever used to be a failed Future
in the past is a fatal\terminal error in the context of IO
... am I getting it right? Is this a supported use case?
Hello @eliavlavi
Your understanding is correct. It's similar with fromTryEither
It's equivalent of IO.deferFuture(f).hideErrors.rethrow
.
Unfortunately, there's no built-in operator for that but I think we really need it if you're interested in contributing.
I see that I even implemented TaskFromFutureEither
in low-level code but I don't remember why I didn't expose it in the API :sweat_smile:
IO.scala
right under def fromFuture
to me, but I am not sure where should the test go - TaskFromFutureSuite.scala
? new file?)
@WesselVS You can do a conversion like this: https://bio.monix.io/docs/cats-effect#monixevaltask
I have some plans to make Observable
easier to use with IO[E, A]
(without conversions) but it is not a top priority for me right now
def liftErrors[E, T](
task: Task[T]
)(pf: PartialFunction[Throwable, IO[E, T]]): IO[E, T] =
task.onErrorHandleWith(ex => pf.applyOrElse(ex, IO.terminate))
IO
with (implicit ev: E <:< Throwable)
and I'm not sure about the name. I feel like it could make sense if onErrorRecoverWith
would work like that but it's not an option now. Maybe new variant of mapError
and flatMapError
( the latter is missing atm), something like mapErrorPartial
/mapErrorSome
/ mapErrorOnly
(whatever would be more consistent with other libraries)
onErrorRecoverWith
for Task
fixes the resulting error type to Throwable
onErrorRecoverWith[E1 >: Throwable, B >: T](pf: PartialFunction[Throwable,IO[E1,B]]): IO[E1,B]
I plan to keep maintaining it but my focus is currently on a monix/monix update for Scala 3 and CE3 which are also blockers for bio.
I think it's possible to get Scala 3 release before the official one but I won't make any promises
Regarding long-term plans, it is hugely dependant on the outcome of the "core" Monix CE3 update but the direction is not clear at the moment so it's difficult for me to provide any details. :sweat_smile: I know for sure that I'd like to have a competitive IO[E, A] implementation that works well with various ecosystems of libraries