Repository navigation
Hot-Reloading Configuration #48
Description
Status (2026-08-20): being delivered via the settings-directory design — validation landed in PR #500; boot loading + key migration, then reload triggers, follow. JSON Schema follow-up in #506. See the status comment below for the full sequencing.
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.
Metadata
Metadata
Assignees
Type
Projects
- Status
Activity
[-][feature] Hot-Reloading Configuration[/-][+]Hot-Reloading Configuration[/+]chore: claude code native improvements (#147)
taitelee commentedon Aug 20, 2026
Status update — this is now being delivered via the settings-directory design rather than re-parsing
config.yaml: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.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).hot-reload-config, f506b5f) keeps the reusable mechanisms — trigger serialization onto one code path and the atomic snapshot swap at the record boundary.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.taitelee commentedon Sep 10, 2026
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.