You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sending a mix of string and buffer payloads into a streaming split node results in what appears to be incorrect triggering of Complete nodes.
Expected Behavior
A Complete node should only be triggered for a message after it has been processed. In the case of a Split node, processed means that the input data has been fully output. In the current implementation, it is possible to receive a Complete trigger before the received data is output by the Split node.
Steps To Reproduce
Use the flow below to see the problem. The (condensed) output is
DONE (string "aa")
[0x61]
[0x62]
[0x62]
DONE (with buffer that generated 0x61, 0x62, and 0x63 output)
"aa"
DONE ??
Output 1 is unexpected as string "aa" hasn't been output until step 6.
The expected output is:
[0x61]
[0x62]
[0x62]
DONE (with buffer that generated 0x61, 0x62, and 0x63 output)
The Split node has only ever been tested with streams of consistent types of payloads. It is quite uncommon to have a source of data that sometimes sends strings and sometimes sends buffers and to need to treat them as a single stream.
So I'm not sure how valid this issue is - or at least, how much of a priority it is to address.
That said, I did note in my comments on #4000 there is a different in behaviour of when done is called between String and Buffer handling... so maybe that's what we should focus on.
So I'm not sure how valid this issue is - or at least, how much of a priority it is to address.
Understood.
It is quite uncommon to have a source of data that sometimes sends strings and sometimes sends buffers and to need to treat them as a single stream.
I'm sure! From your comment, I think you are saying that the intent is that there is one stream that can contain strings and buffers. But, a given instance sees only one or the other.
The implementation more-or-less assumes that there are two different input streams, one for strings and one for buffers. The state for each is mostly maintained separately. They overlap on the done handling, which is what causes the strange behaviors.
For the MCU Edition, to try to match that, I implemented it as two completely separate streams, including the done handling. That gives a very predictable behavior, at least. Here's my code, for reference. Notice that, like the full Node-RED code, it begins by checking the type of the input data.
When I first encountered the Split node, I thought it was odd that it wasn't configured for a particular type of input (buffer, stream, array, object) but instead carried the configuration for all of them. That can't be changed, of course.
It feels messy to try to support both strings and buffers in a single stream. Currently the output type is based on the input type: what would the output be on mixed input?
An easy compromise to implement could be to lock the stream to either buffer or string based on which it encounters first. If the other appears, that's an error. That would give predicable, consistent behavior. The risk is possible compatibility issues.
Current Behavior
Sending a mix of string and buffer payloads into a streaming split node results in what appears to be incorrect triggering of Complete nodes.
Expected Behavior
A Complete node should only be triggered for a message after it has been processed. In the case of a Split node, processed means that the input data has been fully output. In the current implementation, it is possible to receive a Complete trigger before the received data is output by the Split node.
Steps To Reproduce
Use the flow below to see the problem. The (condensed) output is
Output 1 is unexpected as string "aa" hasn't been output until step 6.
The expected output is:
Example flow
Environment
The text was updated successfully, but these errors were encountered: