Are there unchecked casts in how monad fx operates? I’ve run into an issue where (in summary) ```Opt...

# arrow

[kyleg]

Are there unchecked casts in how monad fx operates? I’ve run into an issue where (in summary)

OptionT.fx {
  val x: Foo = OptionT(getFoo()).bind()
  val y: Bar = OptionT(getBar()).bind()
}.value().fix().unsafeRunAsync {}

errors out at val y = … saying cannot cast Foo to Bar. There’s no compile-time error, getFoo(): IO<Option<Foo>> and getBar(): IO<Option<Bar>>

Furthermore, for the exact same user input on the exact same data set, it only occurs sometimes. getFoo and getBar wrap DB calls that return Foo? and `Bar?`` to make them IO<Option<Foo/Bar>>

Might be my last question for a while! Tomorrow I go pick up a laptop from a client and boss has been joking that I’m going to be putting on 60 hours a week for a while on a project, and I have a baby due in a week. 😄 God willing, work and the baby are both chill.

[pakoito]

to debug this it’ll be better to start adding type hints

[pakoito]

IMO at some point the type error will surface by itself

[pakoito]

in particular, I’m interested on OptionT.fx this here

[pakoito]

and OptionT(getBar()).bind()

[pakoito]

split it into 3: the getBar, the OptionT wrap, and the bind

[pakoito]

add a type hint for each

[pakoito]

see what happens

[kyleg]

Thanks. I was unpredictably getting the cast errors and also errors about not accessing DB on main thread. I changed those DAO functions to be IO.effect(Dispatchers.IO) { … } instead of ust IO { ..} and that went away, but now the class cast error isn’t happening right now. Will report back if I can narrow it down or replicate consistently.

[pakoito]

cheers!

[pakoito]

hopefully we aren’t getting any stack rewrite shenanigans, we haven’t seen those in forever