01:53 Xliff joined 10:03 sena_kun joined 11:30 sena_kun left 11:31 sena_kun joined
patrickb o/ 19:53
I'm still hunting the cro bug of sometimes not sending a request and thus hitting the header timeout. 19:54
What I have found out: - It's not reproducible. Sometimes it happens on the very first connection attempt, sometimes on a later reconnect. 19:55
- The HTTP2 connection is successfully established (packets on the wire are fine, cro trace shows the setup happening), but in the failure case the `emit` on the request pipeline never reaches the HTTP2::RequestSerializer. 19:57
- It only happens with HTTP2. I can't reproduce it with HTTP1. 20:02
- I the test script is as minimal as a Cro::Client example program can be: gist.github.com/patrickbkr/637e1e4...173dabc5f3 20:04
I'm starting to wonder if this even is a bug in Cro or Rakudo core. 20:05
From all I can see in the code the HTTP2::RequestSerializer should be the thing directly listening at the other end of the supplier used in Cro::Client HTTP2 request supplier. 20:07
Is there a simple way to introspect the listeners of a given supplier? 20:08
I'll ask that last question over on #raku 20:09
20:25 sena_kun left
patrickb OK. I have sprinkled some debug prints around. The consumer directly attached to the supply in the Cro::Client HTTP2 request pipeline is the SerializerExtension. As I suspected. The `emit` does not reach the code in the `whenever` in the error case. 20:41
It seems that this is a problem with rakudo itself and not Cro. I wonder which components are necessary to trigger this as under normal circumstances supplies are super stable. 20:42
I suspect and fear it's a bug in the VM itself.
patrickb tries to trigger it without the JIT
20:43 Xliff left
patrickb Also happens with MVM_SPESH_DISABLE=1. Phew! 20:47
Verified on 2021.12 and 2022.07 20:54