Scala 3 artifact for tapir akka http server

[HenryS1]

I don't see a scala 3 artifact for tapir-akka-http-server on mvnrepository and I assume this is because Akka only had builds for scala 2.

However, Akka recently published artifacts for scala 3 (https://github.com/akka/akka/issues/30243).

Could you please publish tapir-akka-http-server for scala 3 now that the scala 3 Akka artifacts are available.

[adamw]

I'd be happy to, but I think these are only SNAPSHOTs? I don't think it would be wise to release a tapir non-SNAPSHOT artifact depending on such a dependency

[HenryS1]

Yes, it looks like you're right that they are just SNAPSHOTs. I also hadn't realised that while akka has scala 3 artifacts akka http doesn't have them yet https://github.com/akka/akka-http/issues/3891.

[liosedhel]

Hi @adamw! Any chance to have akka-http with cross CrossVersions.for3use2_13 workaround in place and publish Scala 3 artifacts? Same potentially could be done for akka sttp related libraries.

[adamw]

I don't have much experience with for3use2_13 except for some problems in sttp client (https://github.com/softwaremill/sttp/issues/1225), but if you can make it work (either here or in sttp client), I'll be happy to merge :)

[adamw]

akka-http won't be published for Scala 3 under an open-source license, so this unfortunately won't happen - closing.

[PerWiklander]

Hold on, I have a license for Akka and I want to use tapir-akka-http-server and Scala 3. Is this never going to be possible, or is there some sbt magic I can apply to override the correct things? Or do I need to fork and keep a locally published version of tapir-akka-http-server?

[adamw]

@PerWiklander it very well might be, using the approach @liosedhel outlined. Somebody would have to try :)

[PerWiklander]

I tried. Unfortunately Akka Http has drifted a bit (we are on 10.6.1) so I had to port sttp.tapir.server.akkahttp.

I had to fix AkkaServerRequest.headers. Content-Length and Content-Type have private constructors now. But I can't see a reason to instantiate them at all, so I did like this instead:

  override lazy val headers: Seq[Header] = {
    val contentType: String = ctx.request.entity.contentType.toString

    val contentTypeHeaders: Seq[Header] =
      if contentType == EmptyContentType then Seq.empty
      else Seq(Header(
        HeaderNames.ContentType,
        ctx.request.entity.contentType.toString,
      ))

    val contentLengthHeaders: Seq[Header] =
      ctx.request.entity.contentLengthOption.map(length =>
        Header(
          HeaderNames.ContentLength,
          length.toString,
        )
      ).toList

    ctx
      .request
      .headers
      .map(h => Header(h.name(), h.value()))
      ++ contentTypeHeaders
      ++ contentLengthHeaders
  }

I ended up with four failed tests.

1. Send and receive SSE. This requires sttp.client3.akkahttp.AkkaHttpBackend and I didn't feel like going down that rabbit hole now.
2. should return acceptRanges for file head request: ctx.request.entity.contentLengthOption says 0 but the test expects the length of a file
3. should handle ranged HEAD request like a GET request: ctx.request.entity.contentLengthOption says 0 but the test expects the length of a file
4. should return acceptRanges for resource head request: ctx.request.entity.contentLengthOption says 0 but the test expects the length of a file

I guess porting our project to Pekko is the long term solution. We thought we were ok with the new Akka license, but if the community thinks otherwise Akka will die a slow death from now on.

[adamw]

@PerWiklander some headers are treated specially in akka and have to be provided with the Entity as far as I recall. So maybe the correct solution is to modify the properties of the entity that is returned, but that would need a bit more investigating. But in the end, I think in OSS tapir we should keep OSS akka as a dependency.