so you could use the built in msg._msgid that is already in every msg instead ?
I did wonder about using _msgid, but wondered whether I could rely on that. If a message gets cloned does it keep it's id? If yes then it is possible to get two messages with the same id which could be a problem, if no then it is not a reliable means of identifying the original record in the buffer as, it is conceivable the message could get cloned on its way round the loop.
It should be fairly "solid" - if it's cloned it's completely cloned. The only times we create a new one is if it is missing at any point - ie if it's been deleted/removed or people generate a new msg (rather than re-use existing). So if you save you message at the same time as sending to email node then the _msgid that could be passed through to status would be that one. (as a property inside the status msg - as it would have it's own _msgid of course... 
eg - top msg going into email node - bottom coming out of status node (prototype view)
Since _msgid is cloned then you run into the opposite problem, that you can get multiple messages to be sent with the same id, as in this example
[{"id":"c0ac8894.7fa628","type":"inject","z":"d7ff0732.2f81d8","name":"","topic":"Subject","payload":"A message","payloadType":"str","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":164.5,"y":152,"wires":[["ecb852a2.9e36e8","5f5cec59.578e8c"]]},{"id":"ecb852a2.9e36e8","type":"change","z":"d7ff0732.2f81d8","name":"To Fred","rules":[{"t":"set","p":"to","pt":"msg","to":"fred@somewhere.com","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":348.5,"y":126,"wires":[["67f705c0.213b8c"]]},{"id":"5f5cec59.578e8c","type":"change","z":"d7ff0732.2f81d8","name":"To Jim","rules":[{"t":"set","p":"to","pt":"msg","to":"jim@somewhere.com","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":340,"y":180,"wires":[["67f705c0.213b8c"]]},{"id":"67f705c0.213b8c","type":"debug","z":"d7ff0732.2f81d8","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","x":510.5,"y":163,"wires":[]},{"id":"ced1d056.165c3","type":"comment","z":"d7ff0732.2f81d8","name":"Into buffer and off to email node","info":"","x":586.5,"y":129,"wires":[]}]
so ??? - same would be true if you cloned a msg with msg.id...
I'm only talking about trying to help the email node status here.
Right, but if I have access to the whole message then I would insert a msg.id or similar as I put it into the buffer (in my current system I use an sqlite db and use the db record autoincrement index). If I don't have access to the whole message (which I thought is what you were suggesting) then I can't do that. Perhaps I misunderstood what you meant when you said "you could use the built in msg._msgid that is already in every msg". I can't do that because multiple messages can have the same id.
So where are you adding msg.id ? If you delete msg._msgid in the change nodes it will generate a new one on each leg.
[{"id":"ff3624c9.134098","type":"inject","z":"db8bd33.4e7c83","name":"","topic":"Subject","payload":"A message","payloadType":"str","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":150,"y":380,"wires":[["5bbebfc4.c915c","910d186b.7a9548"]]},{"id":"5bbebfc4.c915c","type":"change","z":"db8bd33.4e7c83","name":"To Fred","rules":[{"t":"set","p":"to","pt":"msg","to":"fred@somewhere.com","tot":"str"},{"t":"delete","p":"_msgid","pt":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":334,"y":354,"wires":[["ccee6e0c.ee6b4"]]},{"id":"910d186b.7a9548","type":"change","z":"db8bd33.4e7c83","name":"To Jim","rules":[{"t":"set","p":"to","pt":"msg","to":"jim@somewhere.com","tot":"str"},{"t":"delete","p":"_msgid","pt":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":325.5,"y":408,"wires":[["ccee6e0c.ee6b4"]]},{"id":"ccee6e0c.ee6b4","type":"debug","z":"db8bd33.4e7c83","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","x":496,"y":391,"wires":[]},{"id":"be1d01c8.3e95c","type":"comment","z":"db8bd33.4e7c83","name":"Into buffer and off to email node","info":"","x":550,"y":340,"wires":[]}]
That would work, but I would not do it there, the nodes that manage the sending ore on a separate linked flow in order to separate the functionality, and i want that to be direct drop in replacement for the email node, so i don't want to impose any additional requirements such as the requirement to delete msgid before passing it across, at some point someone would forget. It could be done within the email flow of course but might involve an extra step. Other than that though it should work.
Isn't there a philosophical point here though? I assumed that _msgid is there for the use of the node red code and therefore the user should not make any assumptions about the contents or behaviour of the attribute. So at some point in the future the node-red code might decide that it should behave differently, or change the behaviour when a message is cloned, even decide it is no longer needed. I am not suggesting any of these are likely, but as I said it is more a philosophical point that the user should not make use of internal features of node-RED.
Is there an issue with making the whole message available in the status node? Then the user can do what he likes with it. Another use I can think of is passing the message on to other flows after the sending is successful, and there may be attributes in the message that are nothing to do with sending the email that the user might want to persist to the next section of flow.
The _msgid is there to help tracing messages through the system - so on a good day you could trace a message from end to end and do performance profiling and the like. Of course because we can't enforce that the _msgid is always constant - both due to forking (multiple copies of same message), deletion (accidental or otherwise), or additional (new messages created mid flow) - being able to guarantee from end to end is impossible so it's there on a best can do basis.
The reason for not wanting to pass the complete msg is. If we just pass as-is - ie by reference - then no problem with size (as it's just a reference) - BUT if you do something to the msg in the status leg it will affect the object back in the other path (as there is only one object). The way to stop that is to clone the msg. If we clone it before passing to status then it's a potentially massive object - as emails can tend to be with image attachments for example. Neither scenario is good for what is supposed to be be just a status indication of something.
Which other path?
wherever else you have put msg in your state machine. (and we don't know what other users may do)
I don't understand the conceptual difference between passing the original message out via a status node and the situation with any other node with an input and one output. We already have the situation that if I save something about a message, then pass it on through a node with only one output then later change an attribute of the message that that may change the saved information. So what is the difference between, say, a function node that just passes on the original message and an email node that sends the email then passes on the original message through the status. In fact I still prefer my original suggestion a long time ago that the email node has an output that passes it on when it has finished, and you could raise exactly the same objection in that case.
good point !
In fact it would be nice if the error object was also added in the case of an error, though that is less important.
the catch node gets that already
Yes, but it also doesn't identify the original message (does it?), so it would be necessary to merge the catch and status nodes to tie an error to a particular message. However that is probably not really necessary if it is problematic.
Assuming the node logging an error does it properly, the Catch node will emit the original message that was received that led to the error, with the extra .error property attached.
Oh, yes, so it does. I had forgotten that, sorry. Ignore the last few posts then.
