I am testing a disconnection of a tcp in node. I have an external computer connected to my node-red running on a pi. I set the the keep alive parameter on the pi set as
I pull the ethernet cable out of the external computer after it has started reporting after a couple of minutes I got the following message on the console that I started node-red on.
9 Nov 16:10:12 - [info] Started flows
29 Nov 16:10:12 - [info] [tcp in:743745e5.05653c] listening on port 12000
29 Nov 16:10:12 - [info] [mqtt-broker:Data Server broker] Connected to broker: mqtt://localhost:1883
29 Nov 16:13:03 - [info] [tcp in:743745e5.05653c] Error: read ETIMEDOUT
So node-red detected the error.
I have a catch node set up to catch errors on the [tcp in:743745e5.05653c] using the selected node option. From the catch node I have a debug node but the msg never showed up anything.
Interestingly if I put the status node looking at the same "tcp in" when the connection is made I get 1 connection showing and once the error occurs I get 0 connections.
Anyone got an idea why I would not have seen the the error in the debug node? Should it not catch this condition?
And can someone tell me where/how to look for known defects so I can check that list out.
Looking at node-red source, server errors are sent without a 2nd parameter in the node.send() call so are not caught by the catch node.
This is just the way it is.
(IMHO) I wouldn't like to say if this is something that would or should change (at least not until a major version update) unless it is considered a bug.
NOTE. the 2nd parameter of node.send is normally the msg and since TCP IN doesn't have a msg, this might well be by design.
I did look at the link to the source however I am not a good enough JS programmer to follow the code.
IMHO ...
Generally when I think of a catch then all errors should caught it should not be dependant on if something exists or not. I have in the past done a similar action using python, wait on tcp messages. The try catch there would trap this error. I obviously think it is a defect.
Anyways what I think I will do is setup a watchdog message that if it does not show up then I know the link is down and can handle the exception. Once I get the watchdog again then I can clean things up. Not ideal but good enough for this application.