I am currently using connect-kotlin, a library to use connectRPC on Android. This is a custom protocol built around grpc. With grpc in general, you have non streaming calls (just like normal calls to a REST api) and streaming calls. With streaming calls, a connection to the server is opened and both sides can send data into that stream until it is closed.
The problem now is that Flipper manipulates these streaming calls in a way that makes them contain a body of 0 bytes which the server can obviously not process. Here is an example of what that looks like:
As you can see, the first call fails because it has a body size of 0B. However, the second call which is exactly the same, succeeds. So I would assume that it is the result of a race condition.
I think that the code responsible for this should be here. When timing is bad, connect just wants to read the request body when Flipper is performing the copy operation which has the side effect that the body is empty for a very short period of time.
In the best case, this race condition is solved as when it works, Flipper is super useful to debug streaming calls.
To Reproduce
To reproduce, I created a fork of the connect-kotlin repository and added flipper to it here. To run, clone the repo, cd into the directory and run $ make generate. After that you can open Android Studio and execute examples.android. When the app is opened, select Connect - bidirectional streaming from the menu. In Flipper you will see that the request body is 0B:
🐛 Bug Report
I am currently using connect-kotlin, a library to use connectRPC on Android. This is a custom protocol built around grpc. With grpc in general, you have non streaming calls (just like normal calls to a REST api) and streaming calls. With streaming calls, a connection to the server is opened and both sides can send data into that stream until it is closed.
The problem now is that Flipper manipulates these streaming calls in a way that makes them contain a body of 0 bytes which the server can obviously not process. Here is an example of what that looks like:
As you can see, the first call fails because it has a body size of 0B. However, the second call which is exactly the same, succeeds. So I would assume that it is the result of a race condition.
I think that the code responsible for this should be here. When timing is bad, connect just wants to read the request body when Flipper is performing the copy operation which has the side effect that the body is empty for a very short period of time.
In the best case, this race condition is solved as when it works, Flipper is super useful to debug streaming calls.
To Reproduce
To reproduce, I created a fork of the connect-kotlin repository and added flipper to it here. To run, clone the repo, cd into the directory and run
$ make generate
. After that you can open Android Studio and executeexamples.android
. When the app is opened, selectConnect - bidirectional streaming
from the menu. In Flipper you will see that the request body is 0B:Environment
Flipper 0.236.0 connect-kotlin 0.3.1