can we not read body after using await?

[Dhruv-Garg79]

I tried doing some checks based on headers, which needed a DB call with await. After that I was not able to read body, and it got stuck.

Is that expected behaviour?
would it have worked if I used callbacks instead of async/await keywords?

[uNetworkingAB]

The issue you're describing with uWebSockets.js, based on the discussion context from the GitHub issue #1178, stems from the way uWebSockets.js handles HTTP request bodies in combination with asynchronous operations like await. Let’s break it down and address your questions.

Problem Explanation

In uWebSockets.js, the HTTP request body is streamed and must be read synchronously within the request handler. When you use await (e.g., for a database call), the JavaScript event loop may proceed, and the internal state of the request object can change, potentially making the body unavailable or causing the operation to hang. This is because uWebSockets.js relies on a low-level, non-blocking I/O model, and the body buffer might not be preserved after yielding control with await.

Expected Behavior

Yes, this is expected behavior in uWebSockets.js. The library’s documentation (and community discussions) indicates that the request body should be read immediately in the handler, typically using the onData callback or similar synchronous methods. Using await before reading the body can lead to issues because the underlying buffer may be cleared or the request may time out while waiting for the asynchronous operation to complete.

Would Callbacks Work Instead?

Using callbacks instead of async/await might help avoid this issue, but it depends on how you structure the code. If you ensure the body is read synchronously (or within the onData callback) before invoking any asynchronous operations, you can avoid the problem. Callbacks themselves don’t inherently solve the issue; the key is to read the body immediately without yielding control to the event loop.

For example, a correct approach might look like this:

app.post('/endpoint', (res, req) => {
  let body = '';

  // Read the body synchronously using onData
  res.onData((chunk, isLast) => {
    body += chunk.toString();
    if (isLast) {
      // Now perform async operations, e.g., DB call
      someDbCallWithCallback((dbResult) => {
        // Process headers or DB result
        res.write(Buffer.from('Response'));
      });
    }
  });
});

Here, the body is fully read before any asynchronous operations are performed, avoiding the issue you encountered.

Why Async/Await Causes Problems

When you use await, the JavaScript event loop is allowed to process other tasks, and uWebSockets.js may clean up or invalidate the request object’s body buffer. This is particularly true for streaming APIs, where the body is not automatically buffered unless explicitly handled. The library is designed for high performance and minimal memory overhead, so it doesn’t hold onto the body unless you explicitly read it.

Solutions

1. Read the Body First: Always read the request body synchronously or within the onData callback before performing any asynchronous operations like database calls.

   app.post('/endpoint', (res, req) => {
     let body = '';
     res.onData((chunk, isLast) => {
       body += chunk.toString();
       if (isLast) {
         // Safe to use async/await now
         (async () => {
           const dbResult = await someDbCall();
           res.write(Buffer.from('Response'));
         })();
       }
     });
   });

2. Use a Middleware for Body Parsing: If you frequently need to read the body, consider using or writing a middleware that buffers the body before passing control to your async handlers. However, be cautious, as buffering large bodies can impact performance.

3. Avoid Async in Critical Path: If possible, structure your code to handle headers and body synchronously, then pass the results to an async function for further processing.

Additional Notes

• Check the Headers First: If your checks involve headers (as you mentioned), you can safely read headers synchronously using req.getHeader() before reading the body or performing async operations.
• uWebSockets.js Philosophy: The library prioritizes performance and low-level control, so it requires careful handling of streaming data. Unlike higher-level frameworks (e.g., Express), it doesn’t automatically buffer the request body.
• Community Insights: The GitHub issue (can we not read body after using await? #1178) likely contains similar advice from the community or maintainers, confirming that this is a known pattern when working with uWebSockets.js. If the issue is still open, you might find additional workarounds or updates there.

Recommendation

To confirm the exact behavior or potential workarounds, you could:

• Check the uWebSockets.js documentation for the latest guidance on handling request bodies.
• Review the GitHub issue can we not read body after using await? #1178 for any updates or responses from maintainers.
• If you’re still facing issues, consider sharing a minimal code snippet in the GitHub discussion to get specific feedback from the community.

If you need me to search for updates on the GitHub issue or provide a more tailored code example, let me know!

[Dhruv-Garg79]

The only reason I was trying to use await before reading the body was for authentication, so that I could save processing the body in case of an unauthorised request.

Thanks a lot for the detailed explanation @uNetworkingAB. I now understand why it behaves like this.

[uNetworkingAB]

If you absolutely want to reject body data until auth:ed, you can pause the socket. But this still requires handling spurious data so your code still will look the same.

I have forgotten how to pause but you can find it if you ask AI or deepwiki or something like that

[uNetworkingAB]

Ah, yes you call res.pause() and res.resume() when you have authenticated

[Dhruv-Garg79]

Thanks for the info, I will try using this.

[uasan]

Ah, yes you call res.pause() and res.resume() when you have authenticated

@uNetworkingAB Is there a limit on the size of the buffer that will be used during a read pause, is this limit at the OS level?