Flow's env variable not updated or lost

Hello,
I store global parameters for my flow such as a user credential, API server URL, alarm destination emails... into flows' environment variables. I have standard subflows that are re-used in many flows that can get their setting this way so I don't have to configure them one by one.

image

But I'm facing some problems with flow's environment variables (Node-RED 2.2.2 running as docker under AWS Fargate, data folder is persistant in an EBS storage)

  1. The most critical : sometime the password (which is an env of type credentials) resets itself to the default __PWRD__ value. When that happens, my flow becomes totally not-functionnal. I have even been blocked by the auth system because of too many attempt at night with PWRD as the password (I have no added a detector for that issue).
    Other variables are untouched

I can't figure out the reason
I am 100% sure that the container has not restarted:

  • I have a restart detector in my flows (a inject node set for single inject at restart that then push a message to a slack channel)
  • no Fargate logs confirm a restart

Also I already have restarted willingly the container without loosing any env variable

  1. the annoying one : When a variable value is changed and deployed, the new value is not necesseraly taken into account or it may take some time (minutes, a lot of minutes).
    Same, I haven't found anything replicable.
    It happens, sometime, but I can't relate it to anything.

Have anyone faced any of those env variable issue ?

Thanks for any hint or advice on how to track that better.

Some fixes went into 2.2.3/3.x around the handling of password type env vars that would be worth picking up to see if they resolve your problem.

Not sure how that can be explained. Env vars are evaluated and applied at the point in time a flow is deployed. There is no mechanism where an env var value can change whilst the flow is running.

Hi @knolleary

Thanks, I didn't noticed that in the 2.2.3 release notes (not always reading them carefully :slight_smile:) and we are taking some steps to revalidate our flows before upgrading to 3.x
I will try to move to 2.2.3 shortly

For the 2nd point that also puzzle me.
Most often I have a 2 layer env variable:

  • I have a env XXX set at the flow level
  • the subflow also have a XXX variable that default to $XXX
    The idea is that when I put an instance of the subflow in the flow, it will normally inherit the flow's env variable. But still I can override on a given instance without changing the flow's environment variable.
    May be there some edge cases when propagating the flow's env to a subflow's ?

I'll try to qualify better but that's very rare, but when it happens it is quite annoying as there is no way to insure/force the proper propagation of the flow's env value to the subflow an I often have to do the override to be able to move on.