Repository navigation
Hot-Reloading Configuration #48
Description
Activity
- changed the title
[-][feature] Hot-Reloading Configuration[/-][+]Hot-Reloading Configuration[/+]on Apr 16, 2026 - added a commit that references this issue
on May 20, 2026 - moved this from Ready to In progress in WaveHouse Task Board
on Jul 20, 2026 Status update — this is now being delivered via the settings-directory design rather than re-parsing
config.yaml:- PR feat(settings): add settings-directory validation and validate CLI #500 lands the first piece: hot-reloadable settings live in a directory of JSON documents (
roles.json,policies.json,pipes.json,config.json), gated bywavehouse validate [dir]— the single validation pass every consumer of the directory runs. That PR is validation-only; no loading or reload wiring yet. - Next PR: boot loads the directory and adopts it (reload trigger → validate → snapshot swap), and the hot-reloadable keys migrate out of
config.yamlintoconfig.json, with an audit of every config key — which move, which stay boot-tier (per PR feat(settings): add settings-directory validation and validate CLI #500 review discussion). - Reload triggers (fsnotify watcher, SIGHUP, ops reload endpoint) layer on after the wiring. PR feat(config): hot-reload whitelisted fields via SIGHUP or admin endpoint #414 prototyped SIGHUP + an admin reload endpoint against the pre-pivot whitelist design and is being closed as superseded; its branch (
hot-reload-config, f506b5f) keeps the reusable mechanisms — trigger serialization onto one code path and the atomic snapshot swap at the record boundary. - Validate settings files with published JSON Schemas #506 tracks the follow-on JSON Schema work: published schemas per settings file for editor-side feedback, and Go-side schema validation mapped onto the same findings.
On the original examples here: whether log level and metric intervals move into the hot-reloadable
config.jsongets decided in the migration PR's audit —WH_LOG_LEVELis env-only today.- PR feat(settings): add settings-directory validation and validate CLI #500 lands the first piece: hot-reloadable settings live in a directory of JSON documents (
Delivered. The settings-directory design replaced the SIGHUP whitelist from #414: validation and
wavehouse validate [dir]landed in #500, boot loading plus fsnotify/SIGHUP//v1/ops/reloadtriggers with swap-only-on-valid landed in #508, and the boot-config half (unboundWH_*env, unusabledata_dir) landed in #569. JSON Schema follow-up stays in #506. Multi-tenant settings directories are tracked in #583.
Metadata
Metadata
Assignees
Type
Projects
- Status
Problem
Changing a log level or a metric interval currently requires a full application restart, causing a small window of downtime and re-sharding in NATS.
Proposed Solution
Implement a watcher for the configuration file or handle the SIGHUP signal. When triggered, the application will re-parse the config and update internal components (like the LogLevel variable) in real-time without dropping active connections.
Alternatives Considered
Easy endpoint to change LogLevel using a pointer to point at the current log level and change it via that in the logger. This is only for log level though. Probably not the ideal way to approach this.
Additional Context
Any mockups, examples, or references that help explain the request.