No catch of TCP timeout

[garybia]

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

net.ipv4.tcp_keepalive_time = 60
net.ipv4.tcp_keepalive_intvl = 60
net.ipv4.tcp_keepalive_probes = 2

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.

[dceejay]

Are you looking at the complete msg with the debug node ?

[Steve-Mcl]

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.

[garybia]

yes I a looking at complete msg.

[garybia]

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.

BTW you guys are incredible on the support.

Thanks