Provide a Scope per server call (#3197)

[987Nabil]

fixes #3197
/claim #3197

[guersam]

What's the purpose of this Scope requirement?

I'd prefer hiding it from the Routes because it makes users to provide Scope that is not actually used.

[987Nabil]

The Scope has to be here, so that it is "eaten" up by the method. The effect that is returned has no more requirement of scope. That means, it is not possible to use a Scope that extends over a single request from inside a request. That is intentionally

[guersam]

I see. I misinterpreted the code due to this line.

I also wondered if we could do the elimination earlier, RoutePattern#->, Routes.apply or etc. for example, but it could be error prone and let the compiler do more work.

[987Nabil]

No, the routes is the right place. We need to close the Scope in the driver, after netty write is over.
If we eliminate the Scope earlier, we would need to close the scope earlier too.
Else you do route.run(..) and your scope is not closed/provided. That would be a bug

[guersam]

By 'eliminating', I mean something like this:

trait Route[-Env, +Err] {
  def apply(request: Request): ZIO[Scope & Env, Response, Response] = ???
}

case class RoutePattern[A](...) {
  def ->[Env, Err, I](handler: Handler[Scope & Env, Err, I, Response]): Route[Env, Err] = ???
}

Unlike the other environments, Scope is a local requirement per request. I think this encoding reveals the relationship more clearly, but there's two downsides that we need to modify every route forming function including Endpoint DSL and the burden to the compiler of the added type calculation per route . In this respect, I think the current design in this PR is still good.

[987Nabil]

@guersam I tried that out. It complicates the code, has negative impact on type inference and all just to save Scope on the type of Routes seems like a bad trade off

[jgranstrom]

@guersam I tried that out. It complicates the code, has negative impact on type inference and all just to save Scope on the type of Routes seems like a bad trade off

This was my conclusion on #3229 as well, I agree with @987Nabil this is the best approach to not make it very convoluted.

[jgranstrom]

FWIW I tested this on the real world case of #3197 and it looks good.