Wow -- a Channel Wire bug that I didn't find (I've found several, but haven't tried all of the "corner cases"). I can verify that this bug is present in all versions of LabVIEW that support Channel Wires as a "full" feature, namely LabVIEW 2016, 2017, 2018, and 2019.
So having said that, I'll ask the question "Why do that?". I think I would argue that a single element Stream does not need an Abort, as Last Element? will do the same thing, namely immediately shutting down the Channel when the Reader next accesses the Channel.
.
Consider the reason for the Stream -- point-to-point asynchronous transfer of element from Writer to Reader. Streams are usually used for Producer/Consumer designs, where the rate of producing elements may be different from the rate of processing ("consuming") them, and you don't want anything to "block" the rate of Production (typically because this is a time-critical step that needs to run at a known, fixed rate). So you make the Producer do "as little work as possible" (i.e. just "produce" the element, don't try to process it) and run it at the "rate of Production", while the Consumer, you hope, runs (on average) at a rate comparable to the Producer. If it runs slower, data will accumulate in the Stream, which can be OK for the short run.
Now suppose you have a Producer/Consumer Stream pair, and you want to stop everything. The "normal" way for the "normal" Stream is to set "Last Element?" to True on the Writer (and set "Element Valid?" as appropriate). This stops the Reader when that "last element" is processed. If the Consumer has gotten behind in its work, with many elements still to process, this method allows all of the elements to be processed before the Consumer shuts down. Note that this has no effect on the Producer.
But what if you need a "Panic Stop", to stop everything as fast as possible? Then you want a signal that says "Stop, no matter if you have data remaining to process or not". That's where Abort comes in -- Abort means "Stop now and throw away any unprocessed Elements".
So what about a One-Element Stream? The "normal" Stream never blocks the Writer, but the One-Element Stream will block if the Reader hasn't processed its data. Consider a Producer that runs at 1 kHz and sends 10 elements to a Consumer that runs at 1 Hz. It sends the first Element, and the Consumer removes it to process it. It sends the second Element, which is accepted by the Reader. However, the Consumer still has 999 ms to go before it can loop around and access the Reader, meaning that the Producer now is blocked by the Consumer! This is something you generally do not want -- the Producer is, in general, the time-critical loop, and here we are forcing an unexpected "stall" into the loop. The Consumer has now effectively forced the Producer to run at 1 Hz, as this is the rate that the Producer can write to the One-Element Stream.
In the paragraph before the one above, I said that Abort differs from Last Element in being true when Set rather than when "Set and Stream is empty". But if the Stream has only one element, these become the same thing! I suspect that at some point, the Developers realized that "Write with Abort" made no logical sense for One-Element Streams, never created it, but didn't notice that it was showing up in the List of Available Channels as a "Documentation Bug".
I'll try to confirm this and report back here.
Bob Schor
