Retrieve upstream node name/type

[kakyoism]

Using the node event handler

node.on('input', function (input, send, done) {})

I wonder how I can find the name/type of the upstream node, e.g., if my flow looks like "inject => MyNode", then how can MyNode know that its upstream is an "inject" node?

I checked in debugger that input has no such info builtin, there is only the _msgId and payload of the inject node.

Help is much appreciated!

[Steve-Mcl]

Are you building your own type of contrib node or just developing a flow?

What is your reason for wanting to know where the message came from?

[kakyoism]

I'm building my own nodes. I want to tell my own nodes from builtin nodes to have special treatments for each categories.

[Steve-Mcl]

This is not how node-red is designed to work. A node should not know or care about where the message came from.

There is a possibility via custom hooks but before I offer that as a solution can you explain what you mean by "special treatments" and "for each categories" please? There may be an alterative more "node-red" way of achieving your requirements.

[kakyoism]

Because node-red uses single input port and inside custom nodes, we'd need to know which upstream output port serves as the input, especailly when there are joined messages. I'm trying to simplify mapping the upstream output message to the internal input argument of current "node of interest" (NOI).

To this end, I can design all my own custom nodes to have a standard output message layout so that the output/input port mapping can be implicit, but to handle builtin nodes or other thirdparty nodes as upstreams, it is more difficult because they can have arbitrary output messages, so I must identify them first to make them work transparently in my own portmapping scheme.

To give you an example, to work with the inject node as the upstream, I can manually rig the node to have a desired output message layout, but it's another story to work with the change or the switch node, while I can have a field to all my custom nodes so that I know they are mine.

[Steve-Mcl]

@kakyoism

Because node-red uses single input port, I'm trying to simplify mapping upstream output message to the internal input argument current "node of interest"

This is the same for everyone (and is by design)

Your node should simply provide a means of mapping in the UI which can be achieved via the typedInput (or whatever) - which permits the user to specify where in the incoming msg a value exists.

@kakyoism

To this end, I can design all my own custom nodes to have a standard output message layout so that the output/input port mapping can be implicit, but to handle builtin nodes or other thirdparty nodes as upstreams, it is more difficult because they can have arbitrary output messages, so I must identify them first to make them work transparently in my own portmapping scheme

This really is not necessary & not the way we do it. It should be enough to "request" that the node user provides the necessary properties in the message. You can be friendly to the user and employ a typedInput to permit them to put the necessary properties anywhere in the msg (allowing a msg to gather up necessary values in a series flow). You can even do a "duck type" check if required.

Additionally, what is to say a msg coming from a change/switch/csv/whatever isnt OK for your node?

For example, suppose the msg originates from one of your "known" nodes but then passes through a switch or link-out/link-in nodes. Which node do you wish to identify this as coming from?

Also suppose the msg originates from one of your "known" nodes but then passes through a change node that deletes or transforms the properties in the msg!

---

Anyhow, if you insist on taking this path (which no other node in the 4000+ node catalog does that I know of) then you will probably have to use a message hook - but I do not recommend it and depending on the above statements I made, may not even be possible. I also recommend if you head down this avenue, it is clearly documented in your readme. "Message hooks" are described in the docs.

[TotallyInformation]

@kakyoism

To this end, I can design all my own custom nodes to have a standard output message layout so that the output/input port mapping can be implicit, but to handle builtin nodes or other thirdparty nodes as upstreams, it is more difficult because they can have arbitrary output messages, so I must identify them first to make them work transparently in my own portmapping scheme.

To give you an example, to work with the inject node as the upstream, I can manually rig the node to have a desired output message layout, but it's another story to work with the change or the switch node, while I can have a field to all my custom nodes so that I know they are mine.

It is not necessary to have a generic solution because one already exists. As Steve says, most nodes do not and should not know or care about upstream nodes. However, if you have to care for some reason, the simple solution is to use a msg property that is as certain as possible not to clash with something someone else might use.

For example, in uibuilder, I have a set of control msgs that can be produced and come out of port #2 of a uibuilder node. These have a very specific msg structure. That structure can be recognised by things such as the uib-cache node. But at the end of the day, it is still just a msg.

It is common to choose a msg property that starts with an underscore to indicate that it isn't one that flow authors would generally be interested in and followed by something unique. For uibuilder, I would use msg._uib for example.

Your custom node can, of course simply ensure that it adds this property. Just make sure that you only do this where it is really needed. There should be relatively few cases where it is needed.

[kakyoism]

@TotallyInformation Thanks! I've been working with this approach for many scenarios. Looks like I'll have to design a littlbe bit more based on the constraints.