Context Storage Configuration for Persistent Scope Management

Answer to the Core Questions

1. Scope‑to‑store mapping: Node‑RED does not bind a scope to a store statically. Instead, each context.get or context.set call can specify the store name. The default key in contextStorage defines which store is used when no store is supplied.

2. Flush configuration: The localfilesystem store accepts a flushInterval (seconds) that controls how often the in‑memory cache is written to disk. The default is 30 s, but it can be set to any positive integer.

Practical Configuration Steps

1. Define two stores in settings.js:

   module.exports = {
       contextStorage: {
           default: { module: "memory" },
           persistent: {
               module: "localfilesystem",
               options: {
                   flushInterval: 5,   // seconds – adjust for your tolerance
                   base: "./persistent-context"
               }
           }
       }
   };

2. Use the store explicitly in flows:

   // High‑frequency volatile data – keep in memory
   flow.set("temp", value);   // no store argument → default (memory)
   
   // Critical state that must survive crashes
   flow.set("critical", value, "persistent");

3. Verify persistence:
   • Write a key with the persistent store, restart Node‑RED, and confirm the value is still available.
   • Write a key with the default store, restart, and confirm it has been lost.
4. Measure the flush window:
   • After writing a critical key, terminate Node‑RED with kill -9 $(pidof node-red) and restart. The key should still be present if the kill occurs after a flush; otherwise it will be lost.

Configuration Parameters for localfilesystem

• flushInterval – seconds between automatic cache flushes (default 30). Lower values reduce the crash‑loss window but increase disk I/O.
• base – directory where the JSON files are written (default is a context folder under the Node‑RED userDir). Setting this to a dedicated mount or backed‑up volume improves durability.

There is no documented synchronous write‑through mode for this store, so truly zero‑loss guarantees require accepting the flush window or using an external store. On clean shutdown Node‑RED flushes cached context; the loss risk applies mainly to crashes or SIGKILL between flushes.

Things to Verify Before Production

• Confirm the exact option names and defaults (such as flushInterval) for your Node‑RED version by inspecting the bundled settings.js template or the documentation for that release.
• Audit all context.set/get calls to ensure the correct store is supplied for critical data; calls without a store argument silently use the default store.
• Benchmark disk I/O on your target hardware when flushInterval is set to the desired value, especially on SD‑card‑based devices where frequent writes cause wear.

Missing Diagnostic Detail

To give a more precise recommendation on flushInterval, I need to know which Node‑RED version you are running. The default value and option names can vary between releases.