alarms.conf currently mixes alarm detection with action-specific settings such as severity and note. JupiterPerpsPositionIncreaseAlarmAction also contains hardcoded alarm IDs, wallet details, assets, amounts, and trade parameters.
Separate when an alarm triggers from what each action does.
Alarm configuration
Reduce alarms.conf to:
ID ASSET CONDITION TRIGGER
Remove severity and note from PriceAlarmDefinition and ResolvedPriceAlarm.
Configured actions
Keep the existing AlarmAction interface unchanged and introduce:
CompositeAlarmAction continues to implement only AlarmAction. It has no configuration file and simply forwards triggered alarms to all configured actions.
The concrete actions implement ConfiguredAlarmAction and use these files:
The files should live alongside alarms.conf. Each action loads its own file during initialization and uses the alarm ID as the link between the alarm and its action-specific configuration.
If an alarm ID is absent from an action configuration, that action must ignore the alarm.
Action-specific settings
Console: alarm IDs that should be printed.
Pushover: application token, user key, and per-alarm severity and note.
Jupiter position increase: wallet, signer key, and per-alarm asset, direction, collateral amount, position-size delta, and maximum slippage.
Remove the corresponding hardcoded Jupiter action values.
Acceptance criteria
alarms.conf contains only alarm detection and trigger settings.
An alarm may have zero, one, or multiple actions.
Each concrete action owns and loads its configuration.
CompositeAlarmAction remains configuration-free.
Missing alarm IDs are treated as “no action”.
Existing alarm condition, range, and trigger behavior remains unchanged.
`alarms.conf` currently mixes alarm detection with action-specific settings such as `severity` and `note`. `JupiterPerpsPositionIncreaseAlarmAction` also contains hardcoded alarm IDs, wallet details, assets, amounts, and trade parameters.
Separate **when an alarm triggers** from **what each action does**.
### Alarm configuration
Reduce `alarms.conf` to:
```text
ID ASSET CONDITION TRIGGER
```
Remove `severity` and `note` from `PriceAlarmDefinition` and `ResolvedPriceAlarm`.
### Configured actions
Keep the existing `AlarmAction` interface unchanged and introduce:
```java
public interface ConfiguredAlarmAction extends AlarmAction {
String getConfigurationFileName();
}
```
`CompositeAlarmAction` continues to implement only `AlarmAction`. It has no configuration file and simply forwards triggered alarms to all configured actions.
The concrete actions implement `ConfiguredAlarmAction` and use these files:
```text
alarmaction_Console.conf
alarmaction_Pushover.conf
alarmaction_JupiterPerpsPositionIncreaseAlarmAction.conf
```
The files should live alongside `alarms.conf`. Each action loads its own file during initialization and uses the alarm ID as the link between the alarm and its action-specific configuration.
If an alarm ID is absent from an action configuration, that action must ignore the alarm.
### Action-specific settings
* Console: alarm IDs that should be printed.
* Pushover: application token, user key, and per-alarm severity and note.
* Jupiter position increase: wallet, signer key, and per-alarm asset, direction, collateral amount, position-size delta, and maximum slippage.
Remove the corresponding hardcoded Jupiter action values.
### Acceptance criteria
* `alarms.conf` contains only alarm detection and trigger settings.
* An alarm may have zero, one, or multiple actions.
* Each concrete action owns and loads its configuration.
* `CompositeAlarmAction` remains configuration-free.
* Missing alarm IDs are treated as “no action”.
* Existing alarm condition, range, and trigger behavior remains unchanged.
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.
alarms.confcurrently mixes alarm detection with action-specific settings such asseverityandnote.JupiterPerpsPositionIncreaseAlarmActionalso contains hardcoded alarm IDs, wallet details, assets, amounts, and trade parameters.Separate when an alarm triggers from what each action does.
Alarm configuration
Reduce
alarms.confto:Remove
severityandnotefromPriceAlarmDefinitionandResolvedPriceAlarm.Configured actions
Keep the existing
AlarmActioninterface unchanged and introduce:CompositeAlarmActioncontinues to implement onlyAlarmAction. It has no configuration file and simply forwards triggered alarms to all configured actions.The concrete actions implement
ConfiguredAlarmActionand use these files:The files should live alongside
alarms.conf. Each action loads its own file during initialization and uses the alarm ID as the link between the alarm and its action-specific configuration.If an alarm ID is absent from an action configuration, that action must ignore the alarm.
Action-specific settings
Remove the corresponding hardcoded Jupiter action values.
Acceptance criteria
alarms.confcontains only alarm detection and trigger settings.CompositeAlarmActionremains configuration-free.