[BUG] Ox forks don't work inside direct-style server handler methods

[polkx]

Tapir version: 1.11.41

Scala version: 3.7.2

Describe the bug

I'm trying to understand the OX library, and I'm stuck on a problem. I have a simple HTTP server that accepts requests and has a long-running task. So, I immediately return the status code "Accepted" and run the long-running task on a separate thread. The error I get is:

java.lang.IllegalStateException: Forks can only be started inside a concurrency scope, or from other forks started in the scope.

How to reproduce?

//> using scala 3.7.2
//> using dep com.softwaremill.sttp.tapir::tapir-core:1.11.41
//> using dep com.softwaremill.sttp.tapir::tapir-netty-server-sync:1.11.41
//> using dep ch.qos.logback:logback-classic:1.5.18

import ox.*
import sttp.model.StatusCode
import sttp.tapir.*
import sttp.tapir.server.netty.sync.NettySyncServer

import scala.concurrent.duration.DurationInt

object Main extends OxApp:
  def run(args: Vector[String])(using Ox): ExitCode =
    val helloWorld = endpoint.get
      .in("hello")
      .in(query[String]("name"))
      .out(stringBody)
      .out(statusCode(StatusCode.Accepted))
      .handleSuccess { name =>
        println("Request")
        fork(longRunningTask())
        println("Response")
        s"Hello, $name!"
      }

    NettySyncServer().addEndpoint(helloWorld).startAndWait()
    ExitCode.Success

  private def longRunningTask(): Unit =
    println("Start")
    sleep(5.seconds)
    println("End")

Additional information
Endpoint for testing: http://localhost:8080/hello?name=xxx

[lbialy]

Lambda passed to handleSuccess is executed on a thread that is not a child of the OxApp scope. I'd assume that for both .startAndWait() and .start() especially this would be true. @adamw would it be possible for the server to propagate scoping parent-child relationships correctly?

I also think we could improve debugging experience here by capturing the code position / location at any variant's of supervised creation and then propagate that information in the Ox capability so that when a fork captures the cap but gets executed on an unrelated thread, we could print this kind of information:

s"The fork belongs to the scope originating at ${codeLocation}, but it was executed on an unrelated thread named: '${Thread.currentThread.getName}'."

In the future capture checking could mark that lambdas taken by handle* / serverLogic* not to capture structural capabilities if that's not something that we can support.

[adamw]

@polkx Interesting case! :) Indeed it should be possible to use scopes like that - and we have the machinery needed in Ox to use the current scope to fork request-handling in Netty - see the PR.

@lbialy I'll improve the error message in Ox. Regarding:

In the future capture checking could mark that lambdas taken by handle* / serverLogic* not to capture structural capabilities if that's not something that we can support.

entirely theoretically ... will it be possible to require that a certain capability is NOT captured, not stating anything about other capabilities? For example, I might want to say that the code should not capture Ox, but it can capture whatever else (e.g. IO)

[adamw]

@lbialy On second thought ... to implement this:

s"The fork belongs to the scope originating at ${codeLocation}, but it was executed on an unrelated thread named: '${Thread.currentThread.getName}'."

I guess I would need to turn supervised in to a macro? To capture the calling location? This seems a bit as an overkill. Maybe I'll just include the current thread's name, with some more information.

[adamw]

@lbialy see softwaremill/ox#354

[lbialy]

No need to turn it into a macro but a macro of some kind would be necessary. Most of the time the location can be captured using... an implicit location capability that macro provides automatically. See: https://github.com/com-lihaoyi/sourcecode

[lbialy]

We use sourcecode in besom to debug monadic stuff. This is a very simple piece of macro logic and can be inlined into the library if you chose to do so.

[adamw]

@lbialy Ah ok, yeah a capability/implicit makes sense. Though I prefer not to add a dependency just for this single case. If there's more, I'll reconsider :)