we have a crate, xmtp_api_http that is a drop-in replacement for xmtp_api_grpc in the case that we need to use xmtp_mls on the web. This crate is generally working, and all tests in xmtp_mls pass.

Reqwest keeps a connection pool alive when using their library, in order to re-use http connections. For our streaming POST requests in xmtp_api_http, we expect the connection to stay alive for the entirety of the request. Reqwest actually spawns a future when the request is sent to watch the request, and re-add the connection to the pool once the request ends. When used with a single-threaded executor, this blocks execution from progressing, since the POST request we're using is long-lived and doesn't end, the two futures mutually keep each other alive and prevent the other from finishing.

We can fix this by using hyper (the lower-level library reqwest is built upon), and crafting the POST request manually & using a separate connection from reqwest. This will allow our streams to be used in current_thread and prevent blocking the executor.

Relevant tests: test_stream_messages, test_stream_conversations

Note: WebAssembly uses a different connection pooling/stream strategy than native reqwest, so it's to be seen if this is a blocker for webassembly support.

rel: seanmonstar/reqwest#500