The docs for pipeline say "Will stop consuming the from channel if the to channel closes." however currently the go block that is reading results and putting to the to channel does a >!, and checks the return value to stop trying to output the current output value, but then goes ahead and tries to process the next output anyways. Thus, if the to channel is closed, the pipeline will continue reading, processing, and attempting to spit values at the to channel without stop.
Also, even if it did stop, some number of values will already have been read from the from channel (1 may be in-process in the output go block, N may be in the results channel, and N may be parked in flight in process go blocks).
Proposed: One option would be to change the doc string and not promise this behavior. Another would be to cause the close to flow back through the pipeline structure, shutting it all down.
Comment made by: xiongtx
One option would be to change the doc string and not promise this behavior.
The expectation should be that we don't endlessly process inputs when we're not consuming outputs, which would certainly be the case when the to channel is closed.
Tianxiang: I'm inclined to agree with you, just being thorough in listing options.