Incompatible with NodeRed-2.2.x

[bundabrg]

Overview

I experience issues trying to call using the Action nodes since upgrading NodeRed to 2.2.0.

The following log entries occur:

2 Feb 13:25:32 - [info] Starting modified flows
2 Feb 13:25:32 - [red] Uncaught Exception:
2 Feb 13:25:32 - [error] TypeError: RED.settings.functionGlobalContext.get is not a function
    at map (/opt/node_modules/node-red-contrib-actionflows/actionflows/actionflows.js:270:51)
    at EventEmitter.runtimeMap (/opt/node_modules/node-red-contrib-actionflows/actionflows/actionflows.js:593:5)
    at EventEmitter.emit (node:events:390:28)
    at start (/opt/node_modules/@node-red/runtime/lib/flows/index.js:383:12)

According to the devs:

We made some internal changes in Node-RED with how global context is managed - and this error is a side-effect of that.

Using RED.settings.functionGlobalContext as way to access global context was never documented as a suitable way of doing it. The fact these nodes are broken because they took that approach, isn't ideal, but nor have we changed a published API.

We need to think about what to do here - should we revert our change to keep things working, or encourage these nodes to use proper APIs.

Reference: https://discourse.nodered.org/t/problem-with-node-red-contrib-actionflows-since-upgrade-to-2-2-0/57368/11

Possibly related to #18

[SandeepAgarwal13]

Appreciate if this can be handled or if we can be indicated on an alternative. Thanks.

[almico]

For reference, since I experienced this problem using a Home Assistant plug-in, I filed an issue there too.

[Steve-Mcl]

Hi all, in the interest of node-red and understanding the problem (from a point of view of "should we fix this in node-red") I did a fork and created a workaround.

It is my opinion there is no reason for this node to be storing the internal mappings in global context. I have detailed this in the PR #20 .

@Steveorevo, if you wish to discuss, please comment on the PR or hit me up on node-red slack, node-red forum or here as @steve-mcl

How to test this fix...

In your .node-red directory (usually cd ~/.node-red) run the below command to install directly from github

npm i Steveorevo/node-red-contrib-actionflows#pull/20

NOTE: This is only temporary and may change / disappear - the real solution is for a fix to be published to NPM

[bundabrg]

Thanks @Steve-Mcl I can confirm, running HomeAssistant Supervised updating actionflows to the PR version fixes my own immediate problem (my pool thanks you as well).

EDIT: Running NodeRed v2.2.0

[Steve-Mcl]

@bundabrg thanks for letting us know. Hopefully @Steveorevo can look at getting a fix published to npm sooner as more people test the PR

[Steveorevo]

If folks can test, that would be great. I'll try to spin up a VM with the latest NodeRED and do a comparison to the prior working version. I can tell that this will break the documentation for the invoke example. But not sure if

ContextStore.get('actionflows');

can be/is accessible from within a function node. Testing the other examples for nesting, loops, and scopes (global, protected, and private) just need to be verified.

[Steve-Mcl]

Hi @Steveorevo

I can tell that this will break the documentation for the invoke example. But not sure if

ContextStore.get('actionflows');

can be/is accessible from within a function node.

No, ContextStore wont be accessible from within a function node - but doesn't need to be.
The code I added simply defers initialisation until an actionflow node is configured. In essence, ContextStore is just a reference to the REAL node-red global context & is only used in your nodes.
In simple terms, global.get("actionflows") in a function node will still work the same if node-red global context was available when your nodes are initialised.

The difference is - if (for whatever reason) global context is unavailable, the PR creates a dummy context store, that is shared across your nodes so that the actionflows continue to work (apart from obviously the invoke from a function node feature).

Now that I am aware of the invoke feature, there is a choice to make...

1. Go ahead with my PR but raise a node.warn or console.warn that invoke will not work (e.g. "Global Context could not be acquired, calls to invoke will not be possible") due to not having access to global context (everything else continues to work)
2. Remove the part of the PR that creates an internal store but raise a node.error whenever a node tries to run an action (e.g. "Global Context is not available, it is not possible to call any actions")

---

If actionflows were being written today

If actionflows were being written today & we were to collaborate on its design...

1. I would strongly urge you do not use node-red context. Instead, use a shared store object in your node package.
2. To satisfy the dynamic invoke element of actionflows, I would recommend an actual invoke node - OR - allow the user to pass the target node into the actionflow node via a msg property e.g. passing msg.invoke = "my_action" would call the my_action flow.
   • My reasons for that direction are that node-red is intended to be low-code, visual programming. Asking the users to send a msg to an invoke node would provide visual clues as to what is happening. Also, non JS programmers would have a better chance of using and understanding your nodes dynamic invoke features.

---

Hope that helps? Or at least makes sense?

[SandeepAgarwal13]

As a user who is invested heavily into the dynamic invoke functionality , i recommend to continue with PR since it allows it BAU (where dynamic invoke is used) to continue . Create a new invoke node may be time consuming (?) and can be next step.

[SandeepAgarwal13]

I tested the PR using 2.1.4 and it works even on the older version. The dynamism. Could not test with 2.2.2 as version was uninstalled due to issue.

[Steveorevo]

@Steve-Mcl Yes that makes sense. I'm all for the low-code, visual programming; that's exactly why actionflows was created. We didn't have a way to extend existing flows visually without altering the original flows. An action node is an invoke node, sans the ability to be dynamic; enforcing the visual queue as to what actionflows will be invoked by name.

To do invocation by a JavaScript node was the last item on the documentation for a reason; priority. If it's of little use or no priority for existing users I can simply remove it.

@SandeepAgarwal13 "As a user who is invested heavily into the dynamic invoke functionality...", just to clarify; if we move forward with the PR, dynamic invocation by JavaScript will cease to function as the global context is not available; or did I misinterpret that?

Patience and feedback with my understanding greatly appreciated!

[SandeepAgarwal13]

@Steveorevo Based on my testing of script in PR - i see that calling invoke from the function node continues to work. What i understand and @Steve-Mcl - please feel to correct me like last time - that he does allow global context to be available without needing to calling the current mechanism of functionGlobalContext.

@Steve-Mcl - What does it mean when you say _"if (for whatever reason) global context is unavailable," - what can be such scenarios. I would assume that to happen in case core NR changes. Just to avoid coming back after few days with a new problem,

What i did was a hack test. Instead of installing - i took the updated javascript file. And replaced the original js temporarily and bounced NR. Tested it. Also add a debug in the js just to check that indeed picking @Steve-Mcl 's file. Below snapshot shows my debug. (initRuntimeMapper is a function added by @Steve-Mcl )

Below snapshot shows dynamic invoke working with @Steve-Mcl 's change.

Below is the code of Invoke Relevant Flow.

Let me know if want me to test any other. Have some time.

[SandeepAgarwal13]

@Steve-Mcl - Hope you can find some time on my query on scenarios - where we expect - global context is not unavailable ?

@Steveorevo - Appreciate if you can review and revert - when feasible if above tests suffice or you foresee issues with dynamic invoke.

[Steve-Mcl]

@Steveorevo - regarding your comment...

@SandeepAgarwal13 "As a user who is invested heavily into the dynamic invoke functionality...", just to clarify; if we move forward with the PR, dynamic invocation by JavaScript will cease to function as the global context is not available; or did I misinterpret that?

If you move forward with my PR, the dynamic invocation by JavaScript will NOT cease to function

Please re-read what I wrote previously...

In simple terms, global.get("actionflows") in a function node will still work the same if node-red global context was available when your nodes are initialised.

The difference is - if (for whatever reason) global context is unavailable, the PR creates a dummy context store, that is shared across your nodes so that the actionflows continue to work (apart from obviously the invoke from a function node feature).

---

I dont know if you realise but many folk on the HA platform are having issues due to this issue - because your node is installed in the default config. Would be good if you could implement a fix sooner rather than later?

[Steveorevo]

Yes. I can certainly do that. Thank you for clarification. Was hoping to get further verification; but I understand the urgency. Pushing version ASAP. Keeping this ticket open until it appears.

[Steveorevo]

Version 2.1.2 pushed to NPM, node-red.org updated; but "Manage Palette" may not reflect version number change for several hours.

[Steve-Mcl]

@Steveorevo Good stuff.

Not sure if you are aware but the flows library does not auto update from NPM any more (hasn't done for quite some time).

~~You need to log in to the flows page and request a re-fresh (or just re-add the node)~~

EDIT: Never mind, I see the update is already available in the flows library. 👍

[Steveorevo]

Yup. Updated my node-red-contrib-credentials as well; it only took a half hour to appear in "Manage Palette". We'll see how long till actionflows appears in node-red instances.

[almico]

Just for reference, I do not use dynamic invocation, but, after upgrading, in Home Assistant, to 10.4.0 and updating the component via Manage Palette, the issue I had is now fixed. Thank you so much!

[bundabrg]

I believe this is now resolved. Thanks.

Please reopen if I am mistaken.