Add safe hot-reload so configuration can be changed without restarting the application.
Important behavior
Reload must be transactional:
Read and validate all four files into a candidate configuration.
Activate it atomically only when everything is valid.
On errors or partially written files, log the problem and continue using the last-known-good configuration.
An in-progress Pushover request or Jupiter transaction must continue using the immutable configuration snapshot with which it started.
Alarm state
Reloading alarms.conf is harder because each PriceAlarm contains runtime state such as triggerCount, lastTriggeredAt, previousReached, and ONETIME status.
Use these rules:
Same alarm ID and identical definition: preserve state.
New alarm ID: create new state.
Removed alarm ID: discard its state.
Changed condition or trigger configuration: treat it as a new alarm and rearm it.
Action-only changes must not reset alarm state.
A newly added or changed alarm may trigger immediately if its condition is already satisfied.
Technical considerations
Action configurations are relatively easy to reload by atomically replacing immutable configuration maps.
The current monitors contain fixed alarm lists and WebSocket consumers reference monitors created during startup. These must use a reloadable runtime snapshot.
Adding the first alarm for a new asset may require starting new WebSocket clients; removing the last may require closing them. Alternatively, always monitor SOL, ETH, and BTC.
User-defined variables and system-generated price variables should be kept separately and combined by AlarmVariableResolver. This avoids races between configuration reload and the periodic Jupiter variable refresher.
WatchService handling must support create, modify, delete, and editor-style temporary-file rename operations.
File events must be debounced so reload never reads a half-written file.
Jupiter configuration requires extra care: no transaction may be created from an incomplete or partially validated configuration.
Suggested implementation phases
Hot-reload the three action configuration files.
Hot-reload shared user-defined variables.
Hot-reload alarms.conf with alarm-state preservation and WebSocket topology handling.
Acceptance criteria
Valid changes take effect without restarting.
Invalid changes retain the previous working configuration.
All four files switch as one consistent snapshot.
Alarm state follows the rules above.
Dynamic variables continue updating normally.
Action changes do not rearm alarms.
In-flight actions remain unaffected by later reloads.
No Jupiter transaction can use a partially loaded configuration.
Reload success and failure are clearly logged.
## Background
The alarm application currently reads these files only during startup:
* `alarms.conf`
* `alarmaction_Console.conf`
* `alarmaction_Pushover.conf`
* `alarmaction_JupiterPerpsPositionIncreaseAlarmAction.conf`
Add safe hot-reload so configuration can be changed without restarting the application.
## Important behavior
Reload must be transactional:
1. Read and validate all four files into a candidate configuration.
2. Activate it atomically only when everything is valid.
3. On errors or partially written files, log the problem and continue using the last-known-good configuration.
An in-progress Pushover request or Jupiter transaction must continue using the immutable configuration snapshot with which it started.
## Alarm state
Reloading `alarms.conf` is harder because each `PriceAlarm` contains runtime state such as `triggerCount`, `lastTriggeredAt`, `previousReached`, and `ONETIME` status.
Use these rules:
* Same alarm ID and identical definition: preserve state.
* New alarm ID: create new state.
* Removed alarm ID: discard its state.
* Changed condition or trigger configuration: treat it as a new alarm and rearm it.
* Action-only changes must not reset alarm state.
A newly added or changed alarm may trigger immediately if its condition is already satisfied.
## Technical considerations
* Action configurations are relatively easy to reload by atomically replacing immutable configuration maps.
* The current monitors contain fixed alarm lists and WebSocket consumers reference monitors created during startup. These must use a reloadable runtime snapshot.
* Adding the first alarm for a new asset may require starting new WebSocket clients; removing the last may require closing them. Alternatively, always monitor SOL, ETH, and BTC.
* User-defined variables and system-generated price variables should be kept separately and combined by `AlarmVariableResolver`. This avoids races between configuration reload and the periodic Jupiter variable refresher.
* WatchService handling must support create, modify, delete, and editor-style temporary-file rename operations.
* File events must be debounced so reload never reads a half-written file.
* Jupiter configuration requires extra care: no transaction may be created from an incomplete or partially validated configuration.
## Suggested implementation phases
1. Hot-reload the three action configuration files.
2. Hot-reload shared user-defined variables.
3. Hot-reload `alarms.conf` with alarm-state preservation and WebSocket topology handling.
## Acceptance criteria
* Valid changes take effect without restarting.
* Invalid changes retain the previous working configuration.
* All four files switch as one consistent snapshot.
* Alarm state follows the rules above.
* Dynamic variables continue updating normally.
* Action changes do not rearm alarms.
* In-flight actions remain unaffected by later reloads.
* No Jupiter transaction can use a partially loaded configuration.
* Reload success and failure are clearly logged.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Background
The alarm application currently reads these files only during startup:
alarms.confalarmaction_Console.confalarmaction_Pushover.confalarmaction_JupiterPerpsPositionIncreaseAlarmAction.confAdd safe hot-reload so configuration can be changed without restarting the application.
Important behavior
Reload must be transactional:
An in-progress Pushover request or Jupiter transaction must continue using the immutable configuration snapshot with which it started.
Alarm state
Reloading
alarms.confis harder because eachPriceAlarmcontains runtime state such astriggerCount,lastTriggeredAt,previousReached, andONETIMEstatus.Use these rules:
A newly added or changed alarm may trigger immediately if its condition is already satisfied.
Technical considerations
AlarmVariableResolver. This avoids races between configuration reload and the periodic Jupiter variable refresher.Suggested implementation phases
alarms.confwith alarm-state preservation and WebSocket topology handling.Acceptance criteria