If you don't do something else with it, that would seem to be the logical conclusion.
Trying again might cause livelock, trying again with a delay would cause undersubscription and maybe still livelock.
You could buffer the value inside the Body and try again during the next execution, or use an external buffer_node.
If you externalise you have the possibility to introduce flow control.
Disclaimer:I think that the documentation needs some TLC, so that will be my excuse if I'm mistaken. :-)
So connecting a multifunction_node to a rejecting node is probably a bad idea.
I would like to achieve something like this:
overwrite_node -> function_node with single in multiple out (i.e. multifunction_node) -> other node -> function_node
Where if the last function_node (or some other) rejects a message it will cause the overwrite_node to drop messages but any message that has passed the overwrite_node must be completed (i.e. the message can become active with a try_get).
This seems to work if it wasn't for the need of the multifunction_node.
Now that I think about it. multifunction_nodes are very dangerous.
If I connect a multifunction_node to a function_node with limited concurrency messages can simply disappear. Which can be very surprising to developers...
Either multifunction_node should be removed from the API or the documentation should very explicitly warn about this.
> to a function_node with limited concurrency
You'd better say with disabled internal buffer (aka rejecting policy). A function_node with queuing policy and serial concurrency will handle all incoming messages.
Please, do not recommend removing multifunction_node. It is extremely useful. Only this node can produce any number (0 or >1) of outgoing messages per one incoming message.