Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 17:54
    cedricblondeau starred http4s/http4s
  • 16:53
    scala-steward closed #570
  • 16:53
    scala-steward commented #570
  • 16:53
    scala-steward opened #572
  • 16:53
    scala-steward commented #4970
  • 16:53
    scala-steward opened #4985
  • 16:52
    scala-steward closed #547
  • 16:51
    scala-steward commented #547
  • 16:51
    scala-steward opened #548
  • 04:35
    armanbilge synchronize #4938
  • 04:15
    armanbilge synchronize #4938
  • Jul 25 05:37
    scala-steward opened #4984
  • Jul 24 18:11
    nasadorian edited #4981
  • Jul 23 16:27
    diesalbla synchronize #4983
  • Jul 23 14:37
    diesalbla opened #4983
  • Jul 23 12:54
    mcenkar edited #4982
  • Jul 23 12:53
    mcenkar opened #4982
  • Jul 23 05:28
    nasadorian edited #4981
  • Jul 23 05:27
    nasadorian opened #4981
Drew Boardman
@drewboardman
Hey, I noticed that the http4s giter8 template throws no main class detected when you sbt run
Drew Boardman
@drewboardman
i even added a mainClass in (Compile, run) := Some("com.drew.example.Main") to my build.sbt, and I'm still seeing that error
I also tried sbt runMain "com.drew.example.Main"
this is just with the raw g8 scaffold, no changes
Ryan Peters
@sloshy
Hmm... I ran it last night and it worked correctly for me
Drew Boardman
@drewboardman
anything fishy there?
i selected is_linux_build == true in the scaffold
i couldnt find any documentation on what that did
could that be the culprit?
Ryan Peters
@sloshy
I think that setting might be graalvm-related from the sounds of it
Drew Boardman
@drewboardman
i'll try without it
nvm i was cd'd into the wrong directory, doh
Christopher Davenport
@ChristopherDavenport
@sloshy Difficult to say from that description but definitely does sound like an ember error. I don't know how endpoints4s integrates if it has assumption the ember doesn't fulfill somehow. Just to confirm you are on the most recent version as well? I have a know error where we end up with timeouts on clients, perhaps if I screwed up a pool mechanism somehow that hasn't previously been reported. A minimization would be very helpful.
Ryan Peters
@sloshy
@ChristopherDavenport I'm on v0.21.8 so the latest "stable" but not trunk. I'll see if I have time later this week to reproduce it in a small project.
Christopher Davenport
@ChristopherDavenport
I think this may be it not setting Content-Length and me picking the wrong default thing which I need to fix.
Across the board though I consider it a mistake to not put those in place in whatever is using it.
I should have a better default but people should set either TransferEncoding: chunked or Content-Length headers.
Ryan Peters
@sloshy
So from the sounds of it the endpoints4s http4s integration is not setting the right headers? Do I have that right? Which triggers Ember's default setting
Is having a non-zero default like a de-facto standard across backends or is the way Ember currently does it "the right way" and the bug is technically in endpoints4s?
Christopher Davenport
@ChristopherDavenport
No, I picked a default and aftewards found out what I picked was backwards of what blaze picked. So I should be falling back to chunked encoding, which I'm not presently.
Ryan Peters
@sloshy
Ahh I see
I appreciate the quick response!
Christopher Davenport
@ChristopherDavenport
However... I believe that endpoints4s should set the header.
I can pick a "default" behavior. But really people should specify that encoding as it makes a big difference in how things render.
Ryan Peters
@sloshy
Noted. I'll be sure to file an issue there and maybe contribute a fix
Billzabob
@Billzabob
Is there an existing client middleware to handle 429s and wait the time specified in the Retry-After header before trying again?
Ross A. Baker
@rossabaker
@domaspoliakas I have heard that it's possible, but I have not personally tried. To compile http4s itself against dotty, we have a few dependencies to work through. Our parser library will be the biggest.
I've been busy catching up on extant PRs, but I hope to turn my attention back to that very soon.
@Billzabob It looks like Retry handles it.
Domas Poliakas
@domaspoliakas
@rossabaker thanks for that! I might give it a shot
macakmujo
@macakmujo
hi there, I have problem when I want to create client request inside Router/response, transfer closed with outstanding read data remaining
    client.toHttpApp.run(request)   
or this as well doesn't work ??
val resource = client.run(request)
val response = resource.useIO, Response[IO] => IO(response))
response
Dmitry Polienko
@nigredo-tori

@macakmujo, the body of the Response "lives" until the Resource is closed. So response in your code yields a Response with a body that was already closed.
You probably want to do something like this:

foo <- client.run(request).use { response =>
  makeFoo(response)
  // the body is still alive
)
// the body is closed

where makeFoo: Response[IO] => IO[Foo] consumes all the data from the body before producing a Foo.

Dmitry Polienko
@nigredo-tori

Or, better yet, using EntityDecoder:

foo <- client.run(request).use(_.as[Foo])

See Resource documentation, and look at the type of Client.run etc. to understand what is happening.

macakmujo
@macakmujo
@nigredo-tori no I just want to make request / return response inside router/service like a proxy
ok thx I will try that :)
macakmujo
@macakmujo
I don't need to read or use data from response I just need to respond, like proxy, or load balancer
Dmitry Polienko
@nigredo-tori
@macakmujo, it's difficult in the general case. There's fundamental incompatibility between Client.run producing a Resource[F, Response[F]], and server implementations requiring an F[Response[F]]. There are (hacky) ways to work around that, but they are never pretty.
macakmujo
@macakmujo
so what should I do is there any other compatible client
macakmujo
@macakmujo
I would like to respond with raw response not to decode it
Dmitry Polienko
@nigredo-tori
Although... toHttpApp seems to encapsulate one of these hacks. So toHttpApp should theoretically work. So there's something in your wiring that does something unexpected. E.g. if your Client follows redirects, it can evaluate the Request.body twice, leading to all sorts of trouble.
macakmujo
@macakmujo
I have tried that as well it has the same problem :(
like this client.toHttpApp.run(request)
I tried this as well client.toKleisli(x=> IO(x)).run(request)
macakmujo
@macakmujo
I have default client instance BlazeClientBuilderIO.resource.use { client =>
macakmujo
@macakmujo
it looks like there is not request redirect