I noticed a strange behavior when trying to drag a node from the Node Repository onto a connection that is upstream of a node in paused or queued state:
If you try to drop a node onto the second connection here, it first seems to work and you get a dialog asking for confirmation:
After clicking OK however, nothing happens, which is a bit counter-intuitive.
Maybe the behavior can be improved, either by showing a more informative message in the dialog, or by disallowing the drop behavior in the first place, and showing an icon indicating that this action is forbidden at the current state.
Similarly, Iād suggest to disallow drag-and-drop when the dragged node has an incompatible set of input and output ports, as otherwise you can end up with a lot of lost connections that can be hard to rewire in complex workflows.
These both seem like bugs - definitely the former, and the latter depending on what you mean by āincompatible setā - if you mean that the node being replaced by the drop has input ports of type (A, A, B) then the node being dropped on it must also have (A, A, B) i would be inclined to disagree; if you mean that the node being dropped on it must have at least one A or one B, then i would agree (and this should be the currently implemented strategy.)
Please clarify the āincompatible setā notion for me, and iāll investigate and open JIRA tickets as appropriate.
ā¦ to replace any node that has a single Data input and a single Data output port, e.g. the Row Filter (and vice versa).
While this might be desired behavior when the node being replaced has no connections, it can be disturbing in cases where the node already was fully connected in some workflow context.
Of course you can argue the every node has flow variable ports and therefore your second case holds true, but Iād suggest to distinguish between ports that have connections (that shouldnāt get lost) and any unconnected ports here.
Ok - i see what you mean. Iāll definitely open an issue for the first case once i verify it locally.
For the second case (the one you clarified,) iāve just re-read through our notes from roughly this time last year when we were working on the ādrop existing canvas nodes on to other nodes to replace themā and there is a long storied debate starting with the original āreplace by drop from repositoryā concerning what is ācorrectā port matching behavior. Iāll dig more into this and bring up your points - thanks for your input!
Sure. My critique was merely a suggestion to improve the user experience here. As far as I understood from @quaeler, the current behavior is meant to only allow node replacement when at least one compatible port is kept. In the case I mentioned, this behavior extends to the (hidden) flow variable ports that every node has, and therefore leads to an non-intuitive user experience, IMHO.
But if that has been discussed extensively elsewhere, Iām fine living with the current behavior.
(I was able to verify the first issue locally, both with nodes from the repository and with nodes already on the workflow canvas and opened an issue for this (AP-11772). Thanks again for the report.)
