Conversation
I still need the msg.payload when there is an error, not only when everything is going well.
|
|
I can understand why you may want it - but for naive users I think it is better to not send anything when there is an error, rather than send a (normally) empty [] response that would look like a valid response unless you check for an error. So I'm not (yet) convinced that this a change we should make. You could also use the error to create a dummy payload [] if you need to forward it on - but yes your fix would do that for you. |
I agree that it shouldn't send an error but I do think it should throw an error |
I thought that even if there is an error, send a message.
|
I would suggest a slightly different approach - with largely the same result. You could event remove the node.error() - if you wanted it to be less chatty I created a PR: #1062 |
|
I consider myself a naive user yet I can't imagine why I would want my flows to just stop when there's a problem. Is there any way that my code can be notified of the error and do something in response? |
|
It does send an error - it can be caught with the catch node - which is the standard way we do it for most nodes. |
I still need the msg.payload when there is an error, not only when everything is going well.
Proposed changes
Checklist
gruntto verify the unit tests pass