msg transport - by reference issue
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 2/5
- Geschätzter Aufwand
- Ein halber Tag
- Anfängerfreundlichkeit
- 35/100
- Issue-Typ
- Dokumentation
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Veraltet
- Tech-Stack
- javascript
- Bereich
- documentation
Rechercherichtung
Prüfe den Abschnitt „receiving messages“ der Dokumentation zu creating-nodes/node-js sowie den Unterabschnitt „Writing a function“ von writing-functions. Überprüfe die Aussagen des Issues zu Nachrichtenreferenzen, RED.util.cloneMessage(msg) und der Beibehaltung von Eigenschaften, bevor du entscheidest, welche Hinweise korrekt sind. Als abgeschlossen gilt die Aufgabe, wenn beide Abschnitte das Verhalten und seine Konsequenzen klar erklären, ohne sich gegenseitig zu widersprechen.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Following discussions elsewhere I made a node called "node-red-contrib-diode" after discovering something I should have known already - that messages are passed by referrence, not by value. This can cause issues as someone may use a message twice in a function - sending it out with node-send and then re-using it. Should the receiving function or node alter the message in any way, because it was sent by reference - this can actually damage the original message. "diode" stops this - but I think this should be clearly pointed out in the documentation.
I found this...
ttp://nodered.org/docs/creating-nodes/node-js
Section "receiving messages"
Suggest you add: "Please note that a reference to the original message is passed here. Altering that message could, in edge cases, affect the calling function."
http://nodered.org/docs/writing-functions
Section "Writing functions"
Subsection "Writing a function"...
You say:
"The returned message object does not need to be same object as was passed in; the function can construct a completely new object before returning it. For example:
var newMsg = { payload: msg.payload.length };
return newMsg;
Note: constructing a new message object will lose any message properties of the received message. This will break some flows, for example the HTTP In/Response flow requires the msg.req and msg.res properties to be preserved end-to-end. In general, function nodes should return the message object they were passed having made any changes to its properties."
So firstly - why would construction a new message lose properties of the old. Using the code DaveCJ provided:
var newMsg = RED.util.cloneMessage(msg);
does not lose any of the original message - I tested it... so you seem to be saying NOT to make a new object - but you don't warn of the consequences. Why not change that example to use the code above which will ensure everything is copied across - scrap the warning that data could be lost and instead tell readers that this might slightly increase overhead - but will eliminate any chance of interaction with the original message.
In my diode node - here you see the unprocessed output - and the output through the node - they are identical down to the msgID - except for the payload which I deliberately altered to show the feedback effect.
msg : Object
{ _msgid: "e5a704f0.1a58f8", topic: "", payload: "goodbye", blah: "fred" }
6/26/2017, 2:31:23 PMnode: d9f3747f.7ef978
msg : Object
{ _msgid: "e5a704f0.1a58f8", topic: "", payload: "hello", blah: "fred" }
Hope this is helpful.
- Vorherrschende Sprache
- JavaScript
- Sterne
- 118
- Forks
- 161
- Ø Merge
- 10 Std. 37 Min.
- Gemergte PRs (30 T.)
- 3
Entwicklungsumgebung
Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus node-red/node-red.github.io
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 68/100
node-red/node-red.github.io#327 ·
-
docs/getting-started/local.md: npm command line is now deprecated, use --location=global not -gOffen
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 62/100
node-red/node-red.github.io#280 · 1 Kommentar ·
-
Website updates for Node-RED 5.0Evtl. wieder frei @knolleary hat das vor 133 Tagen übernommen, und es ist kein Pull Request offen. Offen
node-red/node-red.github.io#416 · 1 Reaktion · 1 zugewiesene Person ·
-
Schwierigkeit 1/5 1-3 Stunden Anfängerfreundlichkeit 50/100
node-red/node-red.github.io#384 ·
-
Update TypedInput docs for node type filterEvtl. wieder frei @knolleary hat das vor 484 Tagen übernommen, und es ist kein Pull Request offen. Offen
node-red/node-red.github.io#382 · 1 Kommentar · 1 zugewiesene Person ·
Alle Issues in node-red/node-red.github.io
Ähnliche Issues
-
Edit: RTE News LogoOffencheck:failed logos:edit
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
iptv-org/database#36354 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 4 Tagen
-
agentic-workflows documentation workflow-editor
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
githubnext/gh-aw-workshop#4139 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
CircuitVerse/CircuitVerse#7967 · 1 Kommentar · 1 Reaktion ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
CopilotKit/aimock#491 ·
Maintainer antworten meist innerhalb von 1 Tag
-
cvss-severity:high devguard l3montree-cybersecurity/.../devguard-documentation pkg:devguard/l3montree-c.../devguard-documentation risk:low state:open
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
l3montree-dev/devguard-documentation#338 · 1 Kommentar ·