Just trying to get distributed tracing to actually distribute. It works, so I'm good.
Do you mean the
Effect type class?
so this means your
F[A] can't be Kleisli[G, E, A] because you need an E before you have any hope of getting an A out, so you can't write Kleisli[G, E, A] => A which is basically what Effect is.
So the "reader" effect is incompatible with Effect. You can never have both.
So. Getting rid of an Effect constraint is a big deal.
I guess ember gets away with it by being one big stream? I think the problem is the request has to be an end of the world in most backends.
Which led me to propose typelevel/cats-effect#555
@tpolecat Would especially like your feedback on the fs2.io.tcp changes given your usage in skunk
Packing and loafing around atm but I’ll have a look on ze plane.
I've asked this before I think but… I have a rather deep and complicated bunch of code that produces a ConnectionIO[], and now I need a side-effecty IO value deep inside it… so it would save me a lot of work if I could use ConnectionIO as IO. what's the accepted way to do this again?
(the IO wraps a random UUID)
in this case it's fine because even though you cannot rollback the
IO inside, it's not a big deal
is there any good ways to mock/stub/whatever for a http4s client in testing? I've always had a bad taste about mocking frameworks,because I end up testing that a specific method is called, rather than the specific result. E.g., if I have a service that use the client I want to know that http://foo is called, I want to simulate the response "bar" and that my service gives "baz". I do not (seen from the test) care if this is done using expect, getAs or some other way
no actual http is involved so you can actually use it in unit tests
because that seems slightly weird to me :) especially since I don't want to translate http errors in to exceptions (by default at least), rather I'd like to react selectively on them, e.g. a Not Found might result in a message about creating the resource where a Request Timeout might be cause for using a circuit breaker with exponential timeout and so on, where an exception is something I'd use more for code issues, such as if I try to pass an malformed url to a method
(what I'm trying to say, it's two very different kinds of errors, and I'd like to treat them accordingly :p )
@SystemFw yes I am :) so you'd do something along the lines of (semi pseudocode, I'm slow at writing scala code right now, since my code completion plugin is broken... for once running a pre-release backfires):
def foo() = {
val req = ...
client.fetch(req)(x => {
if (x.status == OK) { /* do this /* }
else if (x.status == ReuqestTimeout) { /* do that */ }
//...
}).unsafeRunSync()
}
you do need to run it manually if you are integrating http4s in a non functional codebase though
I think Ross was saying that inside
fetch you can use an extractor like case Ok(resp) instead of if (x.status == ....)