I am not understanding this "error" message I get when NR starts

General
1

I started NR today and saw this interesting message.

Trying to follow the rabbit I got nowhere fast.

See pictures.

Ok, if the node got an erroneous message... But that "string" would need to come from somewhere.

That text is not something I would be sending as a user string. It would be a function or something like that.

So how would I go about finding out where it comes from?

Screenshot%20from%202019-08-07%2012-54-40
Screenshot from 2019-08-07 12-54-40.png911Ă—599 97.2 KB
Screenshot%20from%202019-08-07%2012-55-13
Screenshot%20from%202019-08-07%2012-55-18
Screenshot from 2019-08-07 12-55-18.png1360Ă—768 119 KB

2

The log messages have a structure:

type - originating node - error

The TypeError is caused by the gate node, see source code.

I suspect it is caused by the error above it: 'Message exceeded maximum number of catches'

What are you injecting ? Or better: what are you not injecting ? The gate requires a control topic as I read it.

1 Like
3

I suspect you need to set msg.topic on your inject nodes. Otherwise you will create an endless "try-catch" loop with your catch node, because you re-inject the error message into gate.

The message 'Message exceeded maximum number of catches' indicates that the catch node has an internal fail-safe to prevent endless loops.

2 Likes
4

In answer:
It is booting, so I am not sure what is getting injected. I hope only the stuff I want.

Shall have to look into it further.

Thanks.

5

Thanks to both of you for the replies:
@kuema and @bakman2

I think I found it.

Else where on another machine I was/am injecting things and they were not really at the right point.

Thus a message got to go to places it wasn't mean to be.

I hope it is now fixed.

Thanks both.

6

Anyway, with the way you wired your catch node, you can run into this situation again, as soon as any other node on this tab fails with an error. If the msg.topic is not set, gate and catch-all will play message ping-pong again. :grinning:

7

So does msg.topic need to be set it will . . . . . fail?

I know what I am doing is problematic. The idea is that I have this block of code that catches errors and helps me track them.

Of course if that block of code has an error.....

But the cause of the error was because I connected/injected a signal in another flow (part of) that was injected in the wrong place.

8

Looking at the code of the gate node, it implicitly requires the msg.topic to be a string. The type check in line 46 needs to be improved. If msg.topic is anything other than a string or undefined, it will raise the TypeError you are seeing, because toLowerCase() is likely not present.

This is also a bug in the gate node, you should raise an issue there, too.

1 Like
9

Yes, ok. But that was exassabated (?) by the error with how I constructed the other part of the flow.

What is annoying I wasn't told/get the flow name.
But maybe that is because of how the error happened. But the catching of them is supposed to be informative.

10

The error message gave you the name of the node and its id. With that information you can instantly get to the node in question whichever flow it is on.

image
image1336Ă—138 46.2 KB

11

Yes, and I agree.

I am only saying that in that piece of code I posted - though not seen as it isn't included - is a part that names the flow from which the error came.

I'm guessing that as the "Telemetry" flow is the main one, the error hasn't gone past that part of the flow by then.
(This was realised shortly before me posting this reply.)

So for humans to see an error and examine it, it is human readable and shows the type of error and from which flow.

12

Good catch. I will fix it shortly. In my defense, the assumption that msg.topic (if defined) will be a string comes from its origin in the MQTT topic, which is required to be one. Clearly, NR does not impose any such restriction. I am still a bit curious as to what @Trying_to_learn was injecting to make all this happen.

1 Like
13

For the record, this is a general issue, not specific to the gate node. If any node downstream of a catch node throws an error, and the catch node is able to catch that error, you will end up with an infinite loop that is halted only by the fail-safe.

14

I think (yeah, I know....) it was an erroneous message that came from a place it shouldn't.

It only happened at/on boot which made it even harder to find.

15

Fixed in version 0.2.4, uploaded to npm.

1 Like