IOLocal to Local Access for Middlewares

[ChristopherDavenport]

End systems seem to require access to the Local[F, Vault] or IOLocal[Vault] to be able to leverage the TextMapPropagators. However currently the [A] =>> IOLocal[A] => F[_] =>> Local[F,A] is private which means any middleware that operates using the expected Local semantics has to request the end user application to do this transformation for them.

I know the desire is to upstream this to cats-effect, however it seems to me that anyone leveraging the java backend for propagators will need this transformation available or write the same boilerplate themselves into their end user application.

https://github.com/ChristopherDavenport/natchez-http4s-otel/blob/otel2/examples/src/main/scala/example/Http4sExample.scala#L41-L64

[armanbilge]

Linking to:

• IOLocal: MTL Local instance & semantics cats-effect#3385

[iRevive]

There is an idea to simplify propagation in a way passing Local[F, Vault] or IOLocal[Vault] downstream is not mandatory.

#182 (comment)
#182 (comment)

[rossabaker]

I can't remember why I pulled LiftIO out of this, but that's basically the first method.

There's talk on #182 ¹ about how best to provide access to the local vault. It didn't really come up until people started exercising propagators.

We could provide some sort of temp package with whatever gets settled on? API is going to need to be rethought if that CE ticket fails. I still believe in that CE3 ticket: things get real weird using IOLocal statefully through arbitrary libraries.

Footnotes

1. It's embarrassing when GitHub tells me how slow I type or how distracted I am... ↩

[lacarvalho91]

We could provide some sort of temp package with whatever gets settled on?

Is this something that we could do for now? Be good to not have to copy paste this Local instance around. Or is it fine to just use kleisli? I'm not really sure when to use one over the other.

[rossabaker]

I see no reason not to provide the instance. The choice between that or Kleisli is really a matter of taste.

Kleisli tends to intimidate people, but shouldn't. Much like IO is a fancy way to build your program as a Function0, Kleisli is a fancy way to build your program as a Function1. There's no hidden fiber state. It's right there in the types. The problem is, it's right there in the types. That Vault is in your face unless you are rigorous about being final tagless. (I am, but I'm old and unfashionable.). And your main method probably involves some type tetris.

Tagless or not, I generally recommend IOLocal. It does weird shit if you use non-Local methods, but properly constrained, it works well with low cognitive overhead.

[armanbilge]

IOLocal is also a lot faster. There is virtually no performance penalty for unused IOLocals tagging along through untraced parts of an app/library. That's far from the case for Kleisli.

[rossabaker]

That performance claim is true, easily demonstrable in contrived benchmarks, and doesn't tend to be meaningful as soon as the return type is RealIO[BloatedBusinessResponse].

[lacarvalho91]

That Vault is in your face unless you are rigorous about being final tagless. (I am, but I'm old and unfashionable.)

@rossabaker I'm a big fan of tagless final, at $work we will be adopting this as we move away from Akka. Just thought it might be nice for you to hear that there are people still advocating for it!

I see no reason not to provide the instance

Cool - thanks, I'll try and raise a PR some point soon.

The choice between that or Kleisli is really a matter of taste

OK thats good to hear, personally I like having that context reflected in my effect type.

doesn't tend to be meaningful as soon as the return type is RealIO[BloatedBusinessResponse]

I was under this impression too, at $work we mostly write microservices that call other microservices/read DBs so I don't see that performance penalty having any meaningful impact on us