Change Details

Depends on D18856. Ref D18857. See D18857. When we receive a length frame but the buffer doesn't have any data yet, we currently emit a pointless 0-length data frame on the channel. For normal chatter this is harmless/valid, but it causes problems when a channel has transitioned into bundle2 mode (probably it indicates "end of stream")? In any case, it's never helpful, so if we're about to read a data block and don't have any data, just bail out until we see some more data. Note that we can't end up here //expecting// a 0-length data block: both the `data-length` and `data-bytes` states already handle that properly.

Depends on D18856. Ref T13036. See PHI275. When we receive a length frame but the buffer doesn't have any data yet, we currently emit a pointless 0-length data frame on the channel. For normal chatter this is harmless/valid, but it causes problems when a channel has transitioned into bundle2 mode (probably it indicates "end of stream")? In any case, it's never helpful, so if we're about to read a data block and don't have any data, just bail out until we see some more data. Note that we can't end up here //expecting// a 0-length data block: both the `data-length` and `data-bytes` states already handle that properly.

Depends on D18856. Ref D18857T13036. See D18857PHI275. When we receive a length frame but the buffer doesn't have any data yet, we currently emit a pointless 0-length data frame on the channel. For normal chatter this is harmless/valid, but it causes problems when a channel has transitioned into bundle2 mode (probably it indicates "end of stream")? In any case, it's never helpful, so if we're about to read a data block and don't have any data, just bail out until we see some more data. Note that we can't end up here //expecting// a 0-length data block: both the `data-length` and `data-bytes` states already handle that properly.