Node-red-context-monitor: A node to monitor a Node-RED context

[TotallyInformation]

@ralphwetzel

Could please check if the latest commit (@GitHub) is able to spot the right path for your system?

No afraid not. I even uninstalled completely, removing the test node as well and restarted then stopped node-red again and installed from GitHub.

This is what my installation looks like (see my alternate installer repo on GitHub for details):

/src/nr - this is where Node-RED is installed
/src/nr/data - this is the userDir

However, it is perfectly possible to have an install that looks like this:

/somewhere/nrinstall
/anotherplace/myuserdir

The correct way to find the node-red code is to use the require.main object. require.main.path gives you the path to the script that started Node-RED. You can work out the relative path from that.

I think that this should always give you the correct answer (untested):

path.join(require.main.path, '../@node-red/runtime/lib/nodes/context/index.js')

[TotallyInformation]

I've tested that and it certainly finds it on my system. However, something goes into a permanent loop then, everything is locked out.

Not sure where that is happening. Certainly the context_manager is found and require'd.

---

Oh, I wonder if the loop is because I didn't add anything to actually monitor? Sorry, I'm out of time to test that.

[ralphwetzel]

Thank you for spending time on testing this.
Your proposal yields the same result on my system as the current implementation - which is even more explicit. If you find a moment to check your console for any log given, that would be very appreciated.

@TotallyInformation

Oh, I wonder if the loop is because I didn't add anything to actually monitor?

Can't be. Without a scope definition, there's no action at all.

We'll see if others are facing similar issues...

[TotallyInformation]

I also always forget that Node-RED sets its install path on an environment variable

process.env.NODE_RED_HOME

@ralphwetzel

If you find a moment to check your console for any log given, that would be very appreciated.

Yes, did that, it isn't reporting any errors when it goes into its black-hole, it just never responds.

[Colin]

@ralphwetzel

The node should now be able to monitor referenced object changes as well

How are you achieving that?

[ralphwetzel]

If the context is used to store an object, this is wrapped into a Proxy.

[Colin]

@ralphwetzel

wrapped into a Proxy.

I didn't know about that feature. Thanks for the education. Though definitely not something to be used for normal code I think. Debugging nightmares would certainly ensue.

[TotallyInformation]

Node-RED's editor events use proxy's around the node data as it is passed to the event callback. It is a way to be able to add more controls around an object without needing to change the original.

[BartButenaers]

@ralphwetzel

The node should now be able to monitor referenced object changes as well - even nested.
Could you please verify? You need to install the latest commit from Github

Hi @ralphwetzel,
Thanks for digging into this!

So when I get the object from the context and I change it, then 2 messages appear:

It might be useful to add in the documentation why - next to the change event message - there is also a set event message. Because that might be confusing for people, because the context.set is never called in this use case.

@ralphwetzel

Feedback welcome - as always!

Are you sure about that?

I have sometimes troubles to analyze which node is responsible for changing a specific flow/global property. It would be nice if I could specify a property name, and that an output message is send containing the id of the node and flow that was responsible for the set/change of the property.

BTW I have not had a look whether this is technically possible or not. Just thinking out loud. Perhaps my question makes no sense, or is a mission impossible...

[ralphwetzel]

@BartButenaers

It might be useful to add in the documentation why - next to the change event message - there is also a set event message. Because that might be confusing for people, because the context.set is never called in this use case.

The standard "event" is set. You'll always get that when you write to the context.
change is an addon - as it compares the previous value against the set value & fires only in case those are different:

@ralphwetzel

This node allows to setup the reference to a context, then sends a message when this context is written to.

It sends a dedicated message on a separate port in case it detects that the value of the context was changed.

Thus you don't need any additional logic to detect the changed case.

@BartButenaers

It would be nice if I could specify a property name, and that an output message is send containing the id of the node and flow that was responsible for the set/change of the property.

The message sent carries the property name as topic - as you might spot in the shot of your latest post. Adding the node/flow ids sounds like a valuable proposal. Thank you!

[BartButenaers]

@ralphwetzel

Thank you!

Nope, thank you!! Very useful node...

[ralphwetzel]

Update: Just released v1.1!

• Fix monitoring functionality when change node writes to context.
• For objects stored in context: Trigger message when properties get written to, even if writing to object reference - as proposed by @BartButenaers
• Support monitoring context that states a property key of an object, e.g. test_value.test_property
• Added test suite with more than 30+ test-cases.

And ... it is supposed to finally run as well on the system of @TotallyInformation !

[TotallyInformation]

@ralphwetzel

And ... it is supposed to finally run as well on the system of @TotallyInformation !

I will test it

However, I seem to have broken something somehow on my dev system so I'll need to find out what foolish thing I did before I can proceed

[TotallyInformation]

Hi, tried multiple times today, even doing a forced npm cache clear and delete node_modules and full reinstall but every time, node-red starts up and then goes into a loop. It gets as far as saying the flows have started and connects to my MQTT broker but a trigger that should fire after a couple of seconds after startup never triggers (it should output to debug but never does).

In addition, I see an extra line in the startup - note the @f:

0|Node-RED | Welcome to Node-RED
0|Node-RED | ===================
0|Node-RED |
0|Node-RED | 10 Nov 10:00:35 - [info] Node-RED version: v3.1.0
0|Node-RED | 10 Nov 10:00:35 - [info] Node.js  version: v18.17.1
0|Node-RED | 10 Nov 10:00:35 - [info] Windows_NT 10.0.22631 x64 LE

0|Node-RED  | 10 Nov 10:00:37 - [info] Loading palette nodes
0|Node-RED  | @f D:\src\nr\node_modules\@node-red\runtime\lib\nodes\context
0|Node-RED  | 10 Nov 10:00:41 - [info] Dashboard version 3.6.1 started at /nr/ui
0|Node-RED  | 10 Nov 10:00:42 - [info] Settings file  : D:\src\nr\data\settings.js
0|Node-RED  | 10 Nov 10:00:42 - [info] HTTP Static    : D:\src\nr\public > /
0|Node-RED  | 10 Nov 10:00:42 - [info] Context store  : 'default' [module=memory]
0|Node-RED  | 10 Nov 10:00:42 - [info] Context store  : 'file' [module=localfilesystem]
0|Node-RED  | 10 Nov 10:00:42 - [info] User directory : D:\src\nr\data
0|Node-RED  | 10 Nov 10:00:42 - [info] Projects directory: D:\src\nr\data\projects
0|Node-RED  | 10 Nov 10:00:42 - [info] Server now running at http://127.0.0.1:1880/red/
0|Node-RED  | 10 Nov 10:00:42 - [info] Active project : uibuilder_next_gen
0|Node-RED  | 10 Nov 10:00:42 - [info] Flows file     : D:\src\nr\data\projects\uibuilder_next_gen\flow.json

Incidentally, this happens even though no node is in my flows.

[ralphwetzel]

I'm really sorry for the disappointing result you're experiencing.

There's one difference (that might have an impact) I can spot from the log you provided: You're using two Context stores. Let me check the consequences...

@TotallyInformation

no node is in my flows

I translate this to "no context-monitor node" ... correct?

[Paul-Reed]

I also noticed that it does not differentiate between 'memory' & 'filesystem' storage.

So for example; 2 contexts with the same name, one saved in RAM and the other saved in the filesystem, results in both being monitored at the same time.

[ralphwetzel]

@Paul-Reed

I also noticed that it does not differentiate between 'memory' & 'filesystem' storage.

Confirmed. Thank you for reporting!

[ralphwetzel]

@TotallyInformation

In addition, I see an extra line in the startup - note the @f:

The @f is a left-over fragment used for debugging - and it confirms (by occasion) that your initial issue is compensated for: The node identifies the correct file path now!

Additionally I spent some hours time walking through the code. Indeed I found something ... related to the application of the Reflect API. I yet wasn't able to trigger any of those findings to generate what you encounter. Nevertheless I fixed them.

If you find time to test once again, you needed to install the latest version from GitHub. Thank you for your support - and patience!

[TotallyInformation]

@ralphwetzel

If you find time to test once again, you needed to install the latest version from GitHub. Thank you for your support - and patience!

I'll see if I can get any time this weekend.

[ralphwetzel]

Update: Just released v1.2!

• New look.
• Added option to show incoming data in the status.
• Some fixes for Reflect API & test suite.