enableGlobalContextStore: false is ignored at runtime when the server config node has no version property (migration v5 forces it back to true)

[hckroeger]

Describe the bug

Disabling "Enable global context store" in the server config node has no effect at runtime if the stored config node in flows.json does not contain a version property. The palette keeps writing all entity states to global.homeassistant on every state change, even though the deployed config clearly contains "enableGlobalContextStore": false.

Root cause (verified against the v0.80.3 sources):

1. On startup, config-server/index.ts runs the stored config through migrate(config):

   this.config = migrate(config);

2. src/helpers/migrate.ts only skips migrations when a version property exists:

   if (schema.version !== undefined && schema.version >= currentVersion) {
       return schema;
   }

   If version is undefined (which is the case for server config nodes created before the versioning mechanism was introduced and apparently never backfilled on save), all migrations from 0 to 6 are re-applied on every startup.

3. Migration version 5 in src/nodes/config-server/migrations.ts sets the flag unconditionally, overwriting whatever the user configured:

   {
       version: 5,
       up: (schema: any) => {
           const newSchema = {
               ...schema,
               version: 5,
               enableGlobalContextStore: true,
           };
           return newSchema;
       },
   },

4. The migrated config is only used in memory and never written back to flows.json, so the editor and the deployed flows keep showing false while the running node behaves as if it were true. There is no visible indication of the mismatch.

Note that other migrations do get reflected in the saved config when the node is edited (e.g. ha_boolean was converted from "" to [] on my instance), but the version property itself was never persisted, so the runtime migration keeps re-running forever.

Impact

This is mostly invisible with the default in-memory context store. It becomes a real problem when a persistent context store is configured (contextStorage: { default: { module: "localfilesystem" } }): the full entity/state mirror (>1 MB on a typical installation, updated on every state change) is then flushed to disk continuously — unnecessary flash wear and CPU on typical Home Assistant hardware — and there is no way to turn it off via the UI.

To Reproduce

1. Use a server config node whose entry in flows.json has no version property (legacy node; removing the property manually reproduces it as well).
2. Open the server config, untick Enable global context store, deploy, restart Node-RED.
3. Open the context sidebar → Global: homeassistant is (re)created and grows with every state change.
4. Delete the homeassistant key in the context sidebar → it is immediately repopulated.
5. Verify via the admin API (GET /flows) that the deployed config really contains "enableGlobalContextStore": false.

Expected behavior

• A migration must not overwrite an explicitly configured value; migration v5 should only set a default when the property is absent, e.g.

  enableGlobalContextStore: schema.enableGlobalContextStore !== undefined
      ? schema.enableGlobalContextStore
      : true,

• Additionally/alternatively: ensure the version property is persisted when a config node is saved from the editor, so runtime migrations don't silently re-run on every start.

Screenshots

No response

Example Flow

Environment Information

• node-red-contrib-home-assistant-websocket: 0.80.3
• Node-RED: v5.0.0 (Home Assistant Community Add-on v22.0.0)
• Node.js: v24.16.0
• Home Assistant: 2026.6.4
• Context storage: localfilesystem as default store (memory default hides the symptom)

Additional context

Workaround

Warning

Adding version alone can break your flows: it stops all migrations from running, so any field in your stored config that still relies on a migration default will be used raw. In my case "ha_boolean": [] (previously fixed up by migration v1 on every start) caused all boolean state matching to silently fail — motion sensors, smoke detectors etc. stopped triggering.

Safe procedure:

1. Stop Node-RED, back up flows.json.
2. On the server config node, add "version": 6 and make sure the migration-provided fields hold sane values — most importantly "ha_boolean": ["y", "yes", "true", "on", "home", "open"] (must not be empty). The status* and *Selector fields from migrations v3/v4 have code-side fallbacks and are uncritical.
3. Start Node-RED, delete the stale homeassistant key via the context sidebar (Global scope).
4. Verify: the key stays deleted, and boolean-based state nodes still trigger.

After this, the setting is honored and the context store remains clean.

[hckroeger]

Follow-up: the workaround has a serious side effect — skipping the migrations breaks ha_boolean (and silently disables all boolean state matching)

After applying the workaround (manually adding "version": 6 to the server config node), all of my server-state-changed nodes configured with state type boolean stopped matching — motion sensors, smoke detector triggers, door sensors, etc. No errors anywhere; the events arrive but never pass the is true condition.

Cause: my stored config contained "ha_boolean": [] (empty array). For years this was harmless, because migration v1 replaced the empty value with the default ('y|yes|true|on|home|open') at every startup:

ha_boolean: schema.ha_boolean || 'y|yes|true|on|home|open',

With version: 6 present, migrate() returns early and the raw empty array is used. TransformState then builds its boolean regex from it:

const regex = `^(${this.#haBooleans.join('|')})$`;

which becomes ^()$ — it matches only the empty string, so every state cast to boolean evaluates to false. Result: 56 nodes in my installation (state type habool / condition type bool) silently stopped working until I refilled the boolean values via the server config UI.

(I'm aware the State Type setting is deprecated as of 0.80.x and slated for removal — but it is still supported, still rendered in the editor under "Deprecated Settings", and widely deployed in long-standing installations. Until it is actually removed, a silent total failure of this path is worth guarding against, especially since the failure mode gives no error and hits things like smoke detector automations.)

Two takeaways for this issue:

1. The runtime-vs-stored divergence cuts both ways: with the missing version property, users can neither disable the global context store (migration v5 overrides it) nor safely add the version property themselves, because their stored config may still rely on other migration defaults being re-applied at runtime.
2. Whatever fix is chosen (non-destructive migration v5, and/or persisting version on editor save), it should probably also backfill migration defaults once, so that stored configs become self-contained.

I've updated the workaround section in the issue description accordingly so nobody else trips over this.