Skip to content

Persistence

mchristegh edited this page Jul 15, 2026 · 1 revision

Resume state on deploy/restart — disabled by default. When enabled, the node survives redeploys and Node-RED restarts with its world intact, instead of waking up amnesiac in waiting.

Not related to Node-RED's "Persistent Context" (the contextStorage option in settings.js). The node manages its own state files, creating and destroying them as needed.

What is saved

Per-source latest values and lastSeen timestamps, the learned source roster, the latch state, the disabled flag, and runtime overrides (settrigger / setrelease / setstale values). State is written to a sensorconsensus-state subdirectory of your Node-RED userDir, one file per node, on every meaningful change.

Staleness flags are deliberately not saved — they are recomputed on restore, which is the whole point:

Restore judges freshness by the wall clock

On startup, every restored source's age is re-evaluated against real elapsed time. A quick redeploy with everything still fresh restores silently — zero events. A long outage restores into the truth: sources past the window come back stale (sourcestale, source: "internal"), and if that costs the quorum, quorumlost follows — rather than the node pretending hours-old readings are fresh.

Restore is transition-silent

Restore never fires Trigger or Release by itself. The latch returns in its saved state, and the first genuine transition after a restore comes from live evaluation — the next reading, staleness expiry, or command.

One documented consequence: a node using the Release quorum-lost policy that restores into quorum-lost stays latched until that first live evaluation (with everything stale, there is no staleness expiry coming — it waits for a reading or command). If your flow must fail safe across restarts even in total silence, send a query-then-evaluate nudge on startup (an inject node set to fire once) or handle the restore-time quorumlost event on output 4 directly.

Lifecycle

  • Deleting the node from the flow (a removal deploy) deletes its state file.
  • A normal redeploy keeps the file — that's what restore reads.
  • Deploying with the persistence checkbox turned off deletes any leftover state file rather than orphaning it.

See Sources Freshness and Quorum for the staleness and quorum concepts, and Heartbeat for the note that heartbeats restart fresh after a restore.

Clone this wiki locally