Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 15:33
    ptrdom synchronize #963
  • 12:09
    ptrdom commented #963
  • 11:49
    julienrf commented #963
  • 11:05
    julienrf commented #969
  • 10:59
    codecov[bot] commented #969
  • 10:48
    julienrf synchronize #969
  • 10:47
    julienrf synchronize #963
  • 10:19
    julienrf opened #969
  • 09:56
    julienrf synchronize #963
  • 08:27
    julienrf closed #968
  • 08:26
    julienrf closed #965
  • 08:25
    julienrf closed #967
  • Dec 01 17:27
    scala-steward commented #966
  • Dec 01 17:27
    scala-steward opened #968
  • Dec 01 17:27
    scala-steward closed #966
  • Nov 30 23:37
    codecov[bot] commented #967
  • Nov 30 23:21
    scala-steward opened #967
  • Nov 30 19:41
    codecov[bot] commented #966
  • Nov 30 19:28
    scala-steward opened #966
  • Nov 29 20:58
    codecov[bot] commented #965
Simon Parten
@Quafadas
Conclusion: no. I'm going to assume adding it is also a non trivial task!
Mark de Jong
@Fristi
Hiya, I added sttp3 support in a PR
Coverage dropped by 0,07% :roller_coaster:
Build failed due that reason :see_no_evil:
Julien Richard-Foy
@julienrf
Hello! I’ve just released endpoints4s 1.4.0 with your latest contributions! https://github.com/endpoints4s/endpoints4s/releases/tag/v1.4.0
Dominic Egger
@GrafBlutwurst
Thanks for the release Julien!
Adriaan Groenenboom
@agboom
Great news, thanks for the release and all the effort!
Milos Nedeljkovic
@minedeljkovic

It seems that format is not generated for parameters in openapi docs , but it is for request and response body content.
For example, this definition

  val foo: Endpoint[(Long, Long, Long), Long] =
    endpoint(
      request = put(
        path / "foo" / segment[Long]("id") /? qs[Long]("long"),
        jsonRequest[Long]
      ),
      response = ok(jsonResponse[Long])
    )

generates parameters without format

  "parameters": [
    {
      "name": "id",
      "in": "path",
      "schema": {
        "type": "integer"
      },
      "required": true
    },
    {
      "name": "long",
      "in": "query",
      "schema": {
        "type": "integer"
      },
      "required": true
    }
  ],

but request and response body content with format

  "content": {
    "application/json": {
      "schema": {
        "type": "integer",
        "format": "int64"
      }
    }
  }

Is this intended?

Julien Richard-Foy
@julienrf
Good catch @minedeljkovic, this is an issue that should be fixed, IMHO. Do you mind filing an issue description in the repository?
Milos Nedeljkovic
@minedeljkovic
Milos Nedeljkovic
@minedeljkovic

Encoding of heterogenous arrays (tuples) in OpenApi docs seems against OpenApi spec.
Example, this definition

  val foo: Endpoint[Unit, (String, Long)] =
    endpoint(
      request = get(path / "foo"),
      response = ok(jsonResponse[(String, Long)])
    )

produces this OpenApi definition for response content (items is an array of SchemaObject)

"content": {
  "application/json": {
    "schema": {
      "type": "array",
      "items": [
        {
          "type": "string"
        },
        {
          "type": "integer",
          "format": "int64"
        }
      ]
    }
  }
}

but, OpenApi spec is explicitly against that. In this part, it's stated:

items - Value MUST be an object and not an array. Inline or referenced schema MUST be of a Schema Object and not a standard JSON Schema. items MUST be present if the type is array.

Now, OpenApi 3.0 does not have a proper encoding for heterogenous arrays, unfortunately, afaik.
But the question is, is producing definition against the spec the right choice, or it might be better to produce (not perfectly precise) approximation that conforms spec?

Julien Richard-Foy
@julienrf
@minedeljkovic I used this source to model the schema of tuples: https://json-schema.org/understanding-json-schema/reference/array.html#tuple-validation but now I learn about prefixItems. Unfortunately, OpenAPI 3.0 does not support them, as you noticed, so yes, I agree that it is better to produce something else, that conforms to the spec.
Milos Nedeljkovic
@minedeljkovic
Dominic Egger
@GrafBlutwurst
Good day everyone, I was wondering if I'm right in the assumption that chunked encoding for files is not yet a thing on http4s-server?
Julien Richard-Foy
@julienrf
Hi @GrafBlutwurst, indeed we didn’t implement it yet. See endpoints4s/endpoints4s#510 We had one issue with the strategy used by the other interpreters
If we fix that issue, we need to update all the other interpreters to be consistent
Would you be interested in contributing to this effort?
Dominic Egger
@GrafBlutwurst
ahhh I looked into the issues but not the PRs, sorry about that.
Yeah I might have a crack at it, gotta check with my co-workers. But imo it would be the best solution for what we need.
Dominic Egger
@GrafBlutwurst
so i merged lucas' branch to mine and got the tests passing, but I must be understanding something wrong with chunking. What does it mean that implementedByEffecttakes a parameter of Stream[IO, Req] => IO[Resp]?
server tests that is
Julien Richard-Foy
@julienrf
It’s for the case of the request entity is streamed, but not the response
Dominic Egger
@GrafBlutwurst
right so it can be assumed that by the time the stream hits implementedByEffect it has been reassembled and the stream only ever contains one element?
Julien Richard-Foy
@julienrf
Yes, that’s the problem we have with the current way of framing chunks
Dominic Egger
@GrafBlutwurst
right, now I understand the conversation much better.
Dominic Egger
@GrafBlutwurst
but that issue is not specific to the http4s implementation is it? it seems to be the same in akka where we get Source[Req, _]
Julien Richard-Foy
@julienrf
Yes
Well, we do the same assumptions on all the interpreters
It turns out that the akka-http interpreters work well with this assumption (chunks are not reframed)
same for play-server
Dominic Egger
@GrafBlutwurst
you wouldn't happen to have a log/dump of the particular errors you encountered due to reframing anywhere?
Julien Richard-Foy
@julienrf
No :( it seems that Travis CI does not have the logs of the tests either
but if you managed to get the tests pass, then it means that it works, no?
Dominic Egger
@GrafBlutwurst

weeeell. the server ones are but there's an exception that doesn't fail the test somehow. client tests are not passing. I just got them compiling. I suspect this bit from http4s docs might be pertinent though:

Next, we want streaming JSON. Because http4s is streaming in its bones, it relies on jawn for streaming JSON support. Most popular JSON libraries, including Circe, provide jawn support, as the code below shows. What’s left is to integrate jawn’s streaming parsing with fs2’s Stream. That’s done by jawn-fs2, which http4s’ Circe module depends on transitively.

I think you hit the nail on the head with what you wrote in the PR
I don't see a way to address this without baking in circe or at least jawn-fs2 into the http4s-client
Julien Richard-Foy
@julienrf
Ah, if that’s a problem we can create separate modules (e.g., http4s-streaming-server)
but I guess there is a high chance that most of the users of http4s also use the http4s-circe module?
Dominic Egger
@GrafBlutwurst
I would suspect most. I'll do some more tinkering to confirm if that's the issue
Dominic Egger
@GrafBlutwurst
hahaha I think we lazified ourselfs to death because we have an F[Stream[F,Resp]] within a Resource.use i just wrote some truly heretical code, but all tests are green. maybe someone smarter than I knows how to do this properly
Dominic Egger
@GrafBlutwurst
https://github.com/rivero-ag/endpoints4s/blob/http4s-chunked-encoding/http4s/client/src/main/scala/endpoints4s/http4s/client/ChunkedEntities.scala#L55 this is some truly cursed code but makes the tests green. If somebody has some good input on how to address this, I'd be very glad. I'm out for the day though
Dominic Egger
@GrafBlutwurst
PR is up to be looked at. It has a couple open points that I don't know how to tackle so I'd be extremely happy for some help
Julien Richard-Foy
@julienrf
@GrafBlutwurst great, I will have a look ASAP, thanks!
Dominic Egger
@GrafBlutwurst
thank you!
Julien Richard-Foy
@julienrf
@GrafBlutwurst I am not familiar with http4s but I have left a couple of comments, let me know what you think
Dominic Egger
@GrafBlutwurst
:+1: thanks!
Dominic Egger
@GrafBlutwurst
you were indeed right @julienrf the other streams need to be forced as well, it was missing tests. I'm currently adding them. Regarding the change of the Endpointsignature, how much of a problem is that gonna be for users since we're gonna break signature compatibility
Dominic Egger
@GrafBlutwurst
also changing the effect type to be Resource wrapped does work!
Julien Richard-Foy
@julienrf
I think it’s okay to introduce a breaking change in the http4s interpreters, if it brings useful features