Hot Reload
Swap a running engine's ruleset from an updated YAML file without restarting the process.
Hot reload lets a long-running BlazeRules process pick up an edited rule file without a restart and without dropping in-flight work. New YAML is compiled and validated off the hot path, and the active ruleset is replaced atomically only if compilation and validation succeed.
PrerequisiteLoad a ruleset first. Hot reload watches the same file (or a different path) for changes; it does not bootstrap an engine that has never had rules.
Enable hot reload
import blazerules
engine = blazerules.RuleEngine()
engine.load_rules("rules.yaml")
# Watch the file and reload when it changes. Polls every 5 seconds by default.
engine.enable_hot_reload("rules.yaml", poll_interval_seconds=5)
# Inspect the current reload state at any time.
status = engine.hot_reload_status()
print(status)| Call | Purpose |
|---|---|
load_rules(path) | Compile, validate, and activate a ruleset. Required before enabling hot reload. |
enable_hot_reload(path, poll_interval_seconds=5) | Start polling path for changes; reload on change. The poll interval defaults to 5 seconds. |
hot_reload_status() | Return the current reload state — use it to confirm a reload happened and whether the last attempt succeeded. |
What happens on reload
When the watched file changes, the engine does the work to validate the new ruleset before it touches the live one:
- The new YAML and any referenced lookups are compiled and validated away from the evaluation path.
- If everything is valid, the active ruleset is swapped atomically.
- If anything fails — bad YAML, unknown fields, duplicate rule IDs, invalid regex, or missing/invalid lookup files — the previous ruleset stays active. A failed reload never leaves the engine in a half-applied or broken state.
- Batches in flight keep the ruleset they observed at batch start. A reload affects subsequent batches, not the one currently being evaluated.
sequenceDiagram
participant W as Watcher (poll)
participant C as Compiler/Validator
participant E as Active ruleset
W->>W: Poll file every N seconds
W->>C: File changed — compile + validate
alt Valid
C->>E: Atomic swap to new ruleset
Note over E: New batches use new rules
else Invalid
C-->>W: Validation error
Note over E: Keep previous ruleset active
end
Lookups reload with the rulesLookup CSVs referenced by relative paths resolve relative to the rules file and are revalidated as part of the reload. A missing or invalid lookup file fails the reload and does not replace the active ruleset — the same all-or-nothing guarantee. Rule files loaded from
s3://can be reloaded the same way.
Windows are stateful across batchesA reload changes which rules evaluate, but window rules accumulate history across batches. If a reload adds or changes a window rule, that window begins building state from the batches that follow the swap. See the Backtesting page for replaying historical batches in order.
Where to go next
Updated 23 days ago