Fredrik Wärnsberg

I think this was fixed in 1.3.0 https://github.com/ghostdogpr/caliban/releases/tag/v1.3.0

@tusharmath yeah, sorry, I've just been strapped on time. I rewrote it using `HttpUtil` which should be optimized enough (and also handle more edge cases from the spec).

Just wanted to chime in, I've been using this for Kubernetes health checks and some very trivial HTTP endpoints by just embedding it my project. Works great, and since zio-web...

Or I guess an alternative could be to change `Source.run/1` to `Source.run/2` and pass in the task module there. Would probably make for a less confusing API, even if it...

Update: I've changed `Source.run/1` to `Source.run/2`, which felt like the cleanest solution of the two. I think the next thing to consider if it's worth keeping `Dataloader.Task` as a protocol...

[Another example](https://github.com/ghostdogpr/caliban/blob/series/2.x/tools/src/main/scala/caliban/tools/stitching/RemoteResolver.scala#L13-L25) of this in the wild (albeit a much less complete one).

@987Nabil I think in part that's because it's specialized for the error to be of type `Option[E]` (which could maybe be handled via keeping the `Http` companion object as well...

Would it be possible to have a release against a snapshot version of zio-http instead since there isn't an RC available at this time? There's been some quite important fixes...

@chaotic3quilibrium something similar to this should work: ```scala import zhttp._ import zhttp.service.Server import zhttp.http.{ Request, Response } import zhttp.http._ override def run = (for { shutdownSignal !! / "stop" =>...

@swoogles I think they're pretty similar. I think the big difference is that by using `interceptZIOPatch` as in your branch we won't be able to catch error or defects, which...