So, another suggestion... How about changing the debug level in your system to try to catch if something is going unnoticed ? If you want to do so you need to change the debug level in your seetings.js file, restart node-RED and then run again some of those test flows that use context and check the initialization log in the console.
Here the lines to change: comment line infoand uncomment line trace
logging: {
// Only console logging is currently supported
console: {
// Level of logging to be recorded. Options are:
// fatal - only those errors which make the application unusable should be recorded
// error - record errors which are deemed fatal for a particular request + fatal errors
// warn - record problems which are non fatal + errors + fatal errors
// info - record information about the general running of the application + warn + error + fatal errors
// debug - record information which is more verbose than info + info + warn + error + fatal errors
trace - record very detailed logging + debug + info + warn + error + fatal errors
// off - turn off all logging (doesn't affect metrics or audit)
// level: "info",
// Whether or not to include metric events in the log output
metrics: false,
// Whether or not to include audit events in the log output
audit: false
}
},
editorTheme: {
projects: {
enabled: true
}
},
contextStorage: {
default: {
module: "localfilesystem"
},
memoryOnly: {
module: "memory"
}
}
so you what I found out is that you cannot just un-comment the line. You need to have
Level: "trace",
or
Level: "info",
and there is a verbose display, which tells me the modules loaded and the flows, but really no errors at this point other than its just not able to do a global.keys() function.
The fellows here are running Windows 10 with me. They report that the global.keys() works on their PC's. I asked Nick if he could dig a little deeper since this would probably affect other Windows users. It's something that does not hinder performance, but you cannot list any of your global variables which I was hoping to do. I have a bunch of globals which I did not want to add flows to just pull up the values in the debug window. I was hoping to "Wow" people with the functionality and debugging features of Node-RED. .
I am hoping that we figure it out soon. or at least find what is causing the behavior of the keys() function to not work. Again, The flow.keys() apparently is working fine. I would assume that Nick/development could look into the source code and see anything that would prevent the global version from acting predictably. Or what is the difference between flow variables and global variables and see how Windows 10 or other would affect behavior between them.
Just to clarify... Why do you think this will affect other windows users if your colleagues who run Windows aren't hitting it?
As I've said, you are the only person who has reported this issue and we need to find what is unique about your environment to cause this issue. So far we've seemingly ruled out almost everything I can think of. So there must be some detail you are overlooking - the smoking gun that you may not realise is even there.
Correcting what i wrote before: the right way to change the debugging level is changing the value of property "lelvel", as you mentioned before.
console: {
// Level of logging to be recorded. Options are:
// fatal - only those errors which make the application unusable should be recorded
// error - record errors which are deemed fatal for a particular request + fatal errors
// warn - record problems which are non fatal + errors + fatal errors
// info - record information about the general running of the application + warn + error + fatal errors
// debug - record information which is more verbose than info + info + warn + error + fatal errors
// trace - record very detailed logging + debug + info + warn + error + fatal errors
// off - turn off all logging (doesn't affect metrics or audit)
level: "trace",
// Whether or not to include metric events in the log output
metrics: false,
// Whether or not to include audit events in the log output
audit: false
}
A somewhat non-standard build as I use a local install of Node-RED but otherwise pretty vanilla as I use it for development.
Hang on, I notice that you are using Node.JS v 8.9 - is anyone else using that version? I think there was a version of 8.x that had some issues wasn't there? Clutching at straws but it might be worth updating Node.JS. You are also a little behind on Windows 10 updates though that shouldn't matter here.
Nick,
Please bear with me/us. I have tried to go through each and every suggestion here. Sometimes 2 and 3 times just to be sure I have not left anything out or have assumed something I shouldn't. It is unfortunate. And I can certainly attest that most of my problems, so far, have been misunderstanding and assumptions on my part. I see that this isn't necessarily a "Windows" thing. All I can ask is due diligence on this matter. This is a frustrating one, apparently for everyone. All I can do is trial and report my failure/success.
I am upgrading Node.js this morning. I will continue to post and read suggestions that I can work on this end.
Thank you Nick, and everyone, for your kind suggestions and support.
Kyle
All,
I upgraded to Node.js v8.12.0 this morning... There are no changes from last week. Node-RED will still not return global context keys from memory.
Nick,
I don't know it is a Windows problem. It may be completely isolated to my laptop. Is it? I'm at the end of my rope.
I was hoping that you had some means of peeking into the source code and finding why Global keys() would behave differently than Flow keys(). Perhaps you have already. I will probably remove it from my W 10 laptop and then try to reinstall on a Windows 7 PC, perhaps when I get some time to do that.
.
I'm at the end of my rope.