Readable event triggers but socket.readableLength returns zero

[davidkjackson54]

Version

16.4.2

Platform

Windows 10

Subsystem

No response

What steps will reproduce the bug?

I am reading specific lengths of data off the readable queue. I check the readableLength to determine how much data I can read.
However, there are occasions when the readable event triggers but the readableLength is returned as zero.

client._socket.on("readable", () => {
        console.log("Readable event triggered");
        console.log(
          `${new Date().toLocaleString()}, Readable Stream has ${client._socket.readableLength} bytes of data available`
        );
        if (client._socket.readableLength === 0) {
          // for some reason the readable event can trigger but there be nothing in the readable queue
          console.log("readable queue is empty");
          return;
        }

How often does it reproduce? Is there a required condition?

This typically happens when TCP has decided to chunk the return of the data. I read what is available then wait for the next readable event to fire, then I find that the readableLength is zero - despite the readable event having triggered.

What is the expected behavior?

readableLength should contain the number of bytes available in the stream after the readable event has triggered.

What do you see instead?

Readable event triggered
9/17/2021, 7:47:19 AM, Readable Stream has 0 bytes of data available
readable queue is empty

Additional information

No response

[ronag]

I believe 'readable' can also be emitted when the stream has "ended", i.e. readableEnded is true.

[ronag]

@nodejs/streams I think we have an edge case where an empty buffer can cause readable to be emitted... we should probably ignore empty chunks?

[ronag]

I don't think this is a bug though...

[davidkjackson54]

I have the "end" event in place but I am not seeing it being triggered.
How can the readable event be triggered when there is nothing to actually read?? That seems like a bug to me..
Otherwise it would appear to defeat the purpose of the event.

Thee doc states:
Event: 'readable'#
History
The 'readable' event is emitted when there is data available to be read from the stream. In some cases, attaching a listener for the 'readable' event will cause some amount of data to be read into an internal buffer.

[mcollina]

Consider this example:

const { Readable } = require('stream')

const r = new Readable({
  read () {}
})

r.on('readable', function () {
  console.log('readable', r.read())
})

r.on('end', function () {
  console.log('end')
})

r.push(null)

null implies EOF and it will trigger 'readable' and 'end'.
There is something to read on the stream, the end of it.

I think we could improve the docs.

[lpinca]

I have the "end" event in place but I am not seeing it being triggered.

@davidkjackson54 are you are to write a reproducible example using only Node.js core modules?

[davidkjackson54]

Unfortunately, it would be quite difficult to create a recreation scenario.
However, as I say, I do have the 'end' event in place and it is not being triggered.
Also, as I mentioned above, despite the readable event being triggered, I am now having to check the length of socket.readableLength and manage it.

I honestly think that it should not trigger the readable event when there is no actual data to read as signified by a readableLength of zero being returned.

[axaysushir]

Should I take this issue? Also, can anyone suggest to me how to get started with this?

[jasnell]

@ronag or @mcollina may have some ideas.

[mcollina]

In https://github.com/nodejs/node/blob/master/doc/api/stream.md#event-readable, we mention

The 'readable' event will also be emitted once the end of the stream data has been reached but before the 'end' event is emitted.

We should note that this implies that .read() will return null in that case.