Fix `undefined (reading 'name')` error when `msg` is from a `http-in` node

[Steve-Mcl]

Description

1. Check constructor is something before attempting to read the name property. This reveals the real exception - which in the case of the HTTP-In msg object was a circular ref error
2. When a msg contains the HTTP In node req/res properties is passed through project-call nodes, detach the properties then re-attach them when the response comes in.

Related Issue(s)

42

Checklist

• [x] I have read the contribution guidelines
• [ ] Suitable unit/system level tests have been added and they pass
• [x] Documentation has been updated
  • [ ] Upgrade instructions
  • [ ] Configuration details
  • [ ] Concepts
• [ ] Changes flowforge.yml?
  • [ ] Issue/PR raised on flowforge/helm to update ConfigMap Template
  • [ ] Issue/PR raised on flowforge/CloudProject to update values for Staging/Production

Labels

• [ ] Backport needed? -> add the backport label
• [ ] Includes a DB migration? -> add the area:migration label

[Steve-Mcl]

It was pointed out on the nodered Slack #FlowFuse channel - why do I set msg.req/msg.req with the strings REQ:${eventId} and RES:${eventId}, why not simply apply req/res if present in the original msg.

Before publishing the PR, I spent a fair bit time mulling this over (e.g. should I just re-add req & res if present originally).

In the end, I left this in as belt and braces. e.g. These temporary strings guarantee the following:

• It was our code that determined the msg was an actual HTTP-In msg
• It was our code that removed the original req/res`
• Verify the MQTT response message has not (intentionally) changed in these properties
• That the msg was originally modified by the Project Nodes before attempting to reattach the original props

[Steve-Mcl]

One point that may be worth considering is to leave the req object in the msg as the down stream flow may wish to use properties of it? I am fairly sure this would stringify without the circular ref errors.

Of course, the user could simply cherry pick properties from req and add them to a separate object/payload if needed.

Thoughts?

[lgrkvst]

/.../ leave the req object in the msg as the down stream flow may wish to use properties of it? I am fairly sure this would stringify without the circular ref errors.

I just checked and msg.req too contains constructors that won't submit to stringification without a custom replacer. Downstream nodes are probably more interested in the res object, and having access to only one of them will probably introduce at least some level of confusion.

I think you've found a good level with the current solution that basically says "handle http entrance and exit on the same level", just like you should follow your guests to the door as they leave.

[Steve-Mcl]

@lgrkvst thanks for the feedback.