All flow envs turned into inFile recently

Hello
I just spotted, that with recent NR updates (unfortunately don't know with which one, I'm currently on v1.3.3), all env variables references used in Change and Switch nodes suddenly switched from default one (which is in-memory) to other one (which in my case is storage one, named inFile)

here is a snippet from my NR config

contextStorage: {
	inFile: { module: "localfilesystem"},
    default: { module: "memory" }
    },

Image below supports my finding that something is wrong: run-time variables are still from default category, while config of Change variable shows "inFile"

After revising all flows, it seems all Change and Switch nodes are affected.
Is it something expected? I would say it could has serious consequences.

Guessing the reason I've changed the order in contextStorage object in configuration. It makes all flows, which weren't explicitly set to "inFile" back to "default"

contextStorage: {
    default: { module: "memory" },
    inFile: { module: "localfilesystem"}
    },

It seems that in recent NR something changed in how "default" is picked up from contextStorage object. I never changed the order before (I was using it in the form presented in OP since adding inFile to it). But NR changed how it interprets it.

Hi @maxym

Can you raise an issue on GitHub?

I think this is more a cosmetic issue in that it is displaying the wrong store name in the UI, rather than it actually using that store. But will need to investigate.

Yes, I'll do that.
Agree it might be cosmetic thing at very fist moment, but saving changes probably save node settings using displayed values.

The only recent change I can think of was the addition of displaying the store name in the input itself. No changes were made to how the value is stored. So I would be surprised it does modify the value. But until I can investigate, I'm just speculating.

I've just checked, it affects drop list selector too incl value which is shown as set.
for:

contextStorage: {
    default: { module: "memory" },
    inFile: { module: "localfilesystem"}
    },

For

contextStorage: {
	inFile: { module: "localfilesystem"},
    default: { module: "memory" }
    },

I'm not seeing that issue. I just updated to 1.3.3 (macOS) and I changed my settings.js to look like yours:
Screen Shot 2021-04-25 at 10.28.58 AM
and put your data into a change node and you can see it worked:


(NOTE: I used web developer tools to darken the inFile's - never saw them in the change node before!)

If you have it set to something explicit (which inFile obviously is) then it works correctly.
I suppose that only nodes which have been defined before adding additional contextStorage method (thus are implicitly set to default) are affected.

So we still don't know if this changes the node configuration itself or if it's just displaying the wrong store when one hasn't been explicitly set?

The test I'm most interested in is whether, after opening the edit dialog, the node is marked as having changed and needing a deploy. And whether after doing a deploy, does the node start using the other store.

Thanks for encouraging me to do further experiments:

After changing configuration, flows remains unchanged functional wise. Of course as long as we can trust that what is exported (using NR export feature) is being executed.

however if I change anything in the node (ie its name), which raise requirement to save it, the code changes. Here is comparison of what changed in node source after node name changed:

left side: values after saving node at time following config was active:

contextStorage: {
    inFile: { module: "localfilesystem"},
    default: { module: "memory" }
    },

right side: original code (see source code below)

Here is a source I made this test for:

[{"id":"6e2ad02c.aa90e","type":"tab","label":"Flow 5","disabled":false,"info":""},{"id":"6ad61007.8e9aa8","type":"inject","z":"6e2ad02c.aa90e","name":"","repeat":"","crontab":"","once":true,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":130,"y":80,"wires":[["d8328be9.16e2f8"]]},{"id":"d8328be9.16e2f8","type":"change","z":"6e2ad02c.aa90e","name":"Config & init setup","rules":[{"t":"set","p":"message_content","pt":"flow","to":"{\"data\":{\"message\":\"Washing mashine has just finished after %s\",\"title\":\"Washing Mashine\",\"data\":{\"attachment\":{\"url\":\"https://www.freepnglogos.com/uploads/washing-machine-png/washing-machine-icon-download-png-and-ico-icon-easy-4.png\",\"content-type\":\"png\",\"hide-thumbnail\":false},\"apns_headers\":{\"apns-collapse-id\":\"WASHING_MACHINE\"},\"push\":{\"badge\":0,\"category\":\"WASHING_MACHINE\",\"sound\":{\"name\":\"default\",\"critical\":1,\"volume\":0.3}}}}}","tot":"json"},{"t":"set","p":"min_working_power","pt":"flow","to":"3","tot":"num"},{"t":"set","p":"max_idle_power","pt":"flow","to":"1.6","tot":"num"},{"t":"set","p":"idle_timeout","pt":"flow","to":"5000","tot":"num"},{"t":"set","p":"data","pt":"flow","to":"{\"date_start\":null,\"date_end\":null,\"work_time\":null,\"work_time_str\":null}","tot":"json"}],"action":"","property":"","from":"","to":"","reg":false,"x":370,"y":80,"wires":[[]]}]

I think the root cause of whole issue is, name of default contextStorage is never stored into the code. It requires additional effort to cover this condition (missing explicit value of contextStorage) and in turn is sensitive on issues like this one which is likely GUI related only.

BTW you can find the issue in GitHub at: Default contextStorage suddenly changed in nodes to another one · Issue #2954 · node-red/node-red · GitHub

Ahh...the issue is that if have more than one contex storage option defined ins settings.js, it picks up the first one as the default. So if you have

     	contextStorage: {
			inFile     : { module: "localfilesystem" },
 			default    : { module: "memory" }

the inFile is listed first.

I went back to a v1.2.6 of NR on a pi and the settings.js is

     	contextStorage: {
 			memory     : { module: "memory" },
			default    : { module: "localfilesystem" }
     	},

yet it picks up the default.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.