[HTTP In] initially does not emit messages

General
21

Actually had a power outage last night, so now it is restarted. The odd "ghost" debug logging stopped. But it seems that this problem was reproducible, since I saw it two times after two restarts now.

And the HttpIn node still behaves in the same way: No messsags, before I alter the parse setting. And I checked nothing is shown on the system console/sysout from Node-Red.

What can I do to troubleshoot this more? Is there some internal debug logging from HttpIn that I can turn on?

22

Did you try it with a JSON node instead of parsing it in the http node? If that does not throw any errors then it must be the http node. It will also give you a solid system that you can keep using.

Also set up another system with just the http nodes (on your pc for example). That will be valuable as it will determine whether it is something specific to the failing device and will also allow you to experiment without impacting your production line.

23

You should be able to capture between the reverse proxy and the node-red instance which will be without TLS.

If both the reverse proxy and node-red are in docker it gets a little trickier because you need to work out which virtual interface to monitor on the host machine, but it shouldn't be that hard as you just need to match up the correct 172.169.x.x IP addresses.

24

Behaviour seems to be exactly the same with the JSON node doing the parsing: Initially nothing comes through (from either node). As soon as I change the parsing setting on the HttpIn node (back and forth), messages start coming through.

I still see the problem of messages being debug-logged to the console, after removing the connecting. But note that I had connections from the HttpIn node and the JSON node, to see both. After removing both connections, I still see the messages through the debug node, but only from HttpIn, not the parsed ones from JSON node.

So more and more indicates there is something odd with the HttpIn node.

I have not had time yet to make a local mock-up to see if I can reproduce the problem.

25

I made a minimal similar setup locally.

Could not reproduce in 4.1.6.

Upgraded to 4.1.8 and thought at first I had reproduced it, but now it works. Might have been a CLI/curl issue, or something. Not sure.

So locally it works. In the prod environment both issues seem to be reproducible.

I now also tried reproducing the issue with my own request to the URL. It is exactly the same: After restart no messages, after changing the setting (even just once, not back and forth) messages start coming through. Exact same data sent with curl.

26

Do you mean that with the json node and the http node initially set to not parse that the http node still did not send anything on startup? If so then it is nothing to do with the parsing itself.

If you are fairly reliably seeing output from a debug node that is not connected to anything, and you have deployed after disconnecting it, then there is something very odd going on, not related to the http node. When it is in the mode of showing output when not connected refresh the browser page and make sure it still shows not connected. Are you accessing the node-red editor through the proxy?
When it is showing debug from the http node, but is not connected to anything, select and export the debug node and the http node and the surrounding nodes and paste the export inline here.

27

Yes, exactly.

I did refresh. Debug node still not connected.

I access the Node-Red UI directly, no proxy involved (only for the outside HTTPS requests; the webhook requests).

Nodes exported while observing messages from debug node:

[
	{
		"id": "7b7819f18938b54b",
		"type": "debug",
		"z": "c52991f9adae8574",
		"name": "debug 6",
		"active": true,
		"tosidebar": true,
		"console": false,
		"tostatus": false,
		"complete": "true",
		"targetType": "full",
		"statusVal": "",
		"statusType": "auto",
		"x": 1600,
		"y": 1340,
		"wires": [

		]
	},
	{
		"id": "e1485ffa11975162",
		"type": "http response",
		"z": "c52991f9adae8574",
		"g": "71a47cccf8402f34",
		"name": "hook response",
		"statusCode": "200",
		"headers": {
		},
		"x": 1080,
		"y": 1340,
		"wires": [

		]
	},
	{
		"id": "a3e79535397072b8",
		"type": "http in",
		"z": "c52991f9adae8574",
		"g": "71a47cccf8402f34",
		"name": "hook",
		"url": "/hooks/car/vehicle",
		"method": "post",
		"upload": false,
		"skipBodyParsing": false,
		"swaggerDoc": "",
		"x": 930,
		"y": 1300,
		"wires": [
			[
				"e1485ffa11975162"
			]
		]
	}
]

I removed the info property, because it contains proprietary information. But that should not affect anything, I think.

28

If you hover over the debug output when it should not be there, does the debug node highlight?

Could you have a look in the flows file (with the wire disconnected but the debug appearing) and search for the text 7b7819f18938b54b, which is the id of the debug node. See if it appears anywhere other than at the start of the debug node itself. For example it might still appear in the "wires" section of the http in node, indicating that the wire to the debug node is still there, but invisible in the browser for some reason.

29

Yes.

This id is only listed once, as the id property for the debug node.

30

Sorry, I am out of ideas. I think we need input from someone who knows more about the internals of node-red than I do.

I suspect that the issue with the http node is purely the fact that you are re-deploying it, rather than the parsing state. You could try changing something else in order to check that. What it has to do with debug messages down non-existent wires I have no idea.

One further thought. could you show us what is in the flows file for the http in node? Delete the text in the info section if necessary but leave the section there. Compare what is in the flows file with that for the node in your local test flow.

31

One other thought. After copying out what is in the http node config, delete the node and recreate it from scratch. Initially without any info text and see if that fixes it. Then put the info text back in.

32

I wrote up a long answer with all kinds of details, but then I think I found the problem. Of course much simpler than I would have guessed:

Another HttpIn for the same URL. That I was not aware of.

Perhaps it would be prudent to implement some kind of warning or validation on unique resources like URL paths? Or deliver any requerst to all nodes listening on that path? Should I create an issue for this?

I have no idea on about the debug output though, as that was clearly sent by the debug node with no connections (according to the orange dotted line, when hovering over the message). Strange. Not sure it makes sense to report this?

In any case: thanks a lot for the efforts everybody!

1 Like
33

Of course, I should have thought of that. Deploying it probably moves it up to front of the execution list so that it gets the request rather than the other one.

That is probably worth while. I don't know whether it is ever valid to have two on the same URL, but if it is then the developers will say so.

Nor do I. Are you still able to replicate it? If so then please post an issue. I have very occasionally seen similar issues but never repeatable.

1 Like
34

Can I just say that it has been a pleasure to deal with someone who reads the posts, acts on them and answers all the questions asked. Often, just getting someone you are trying to help to try things and to answer questions, is extraordinarily difficult.

3 Likes
35

There is an option in the linter config to check on duplicate http-in url's...

1 Like
36

For comparison, mqtt in emits all on duplicate.

37

That is not a valid comparison. MQTT operation from node-red is more like an http request node, not an http In node. Node red sends a request to the mqtt broker to publish or subscribe to a message, and for subscribe events the broker responds with data as appropriate. The equivalent issue with MQTT would be having two mqtt brokers both listening on the same ip/port, which would not work.

38

For reference: FR: Avoid or handle multple HttpIn with same listening URL Ā· Issue #5643 Ā· node-red/node-red Ā· GitHub

39

Yes, you are right, nrlint does have such an option, enabled by default

@dth To install nrlint go to your .node-red folder (assuming this is a conventional install), run
npm install nrlint
and restart node-red. There will then be an additional tab in the right hand pane for linter errors, and nodes with issues will be flagged in the editor.

1 Like
40

Cool, thanks. I didn't know about nrlint. I will make sure to use that.