Guest gets stuck reading from a WASIx Pipe #6760

^{Originally posted by Relecto May 20, 2026}
hi!
I'm working on an unusual project that involves running wasi programs inside a game engine, and ran into a very odd issue with the wasmer runtime, and I was hoping someone would have any suggestions of how to even approach this.

I am using the wasmer rust crate to run a wasi-compiled python interpreter.
The python program can interact with the host by writing to a "device" file backed by wasix Pipe. The communication is a simplistic rpc protocol: the guest writes a request to the file and terminates with \n, the host reads until \n, processes request and writes response terminated by \n.

Now the problem:

1. Communications works fine for the first 47 requests
2. On 48th request, host successfully reads the request, writes response to wasix Pipe, but the guest remains blocked on the read call. The written data never arrives to the host, and it remains stuck.
3. The oddly specific number of 48 is not affected by amount of bytes sent, but it is affected by the number of write calls (see below).
4. If a guest program makes less than 48 requests, it completes successfully. Oddly, if you run a program that makes less than 48 requests first, and then reuse the same store, module, instance, virtual file system and the same wasix Pipes to run a larger program, it runs without issues.

What I tried:

• Remove buffering from both sides - the behaviour is the same even when reading one byte at a time on both sides.
• Run instance _start func using call and call_async, with no difference:

  let start = instance.exports.get_function("_start").unwrap();
  
  // this:
  let result = start.call_async(store_async, Vec::new()).await;
  
  // behaves the same as this:
  let mut store = store_async.write_lock().await;
  let result = start.call(&mut store, &[]);

• Write payload and separator in two .write() calls instead of one:

  // Payload and separator in one write call
  let mut msg = Vec::from(res);
  msg.push(b'\n');
  self.pipe.write_all(&msg).await?;
  self.pipe.flush().await?;
  
  // Payload and separator in different write calls
  self.pipe.write_all(&res).await?;
  self.pipe.write(&[b'\n']).await?;
  
  self.pipe.flush().await?;

  With this change, only 31 requests are successful. 32nd is stuck.

My next step is to try and reproduce this problem in a fresh program, it will take a while, but I would be very thankful if someone could chime in with some ideas on what potentially might cause this problem.

thanks!