Add runtime-updated Jupiter Perps entry price variables to the Jupiter Perps Alarm application.
The alarm config should no longer need manually maintained entry price constants. Instead, the application should be able to fetch open Jupiter Perps positions for a configured wallet and update the same variable map that is also populated by the config file.
Variable model
There is one shared variable map.
Config loading writes variables into this map first.
Runtime refresh may write new variables into the same map.
Runtime refresh may overwrite variables that were originally loaded from config.
There is no source tracking and no conflict rule.
A variable that does not exist resolves to null / unresolved during alarm evaluation.
Wallet configuration
Add one config variable for the wallet address used for Jupiter Perps position lookup:
{{JUPITER_PERPS_WALLET}} <wallet-address>
The wallet address must come from the config file, not from hardcoded Java code.
The runtime refresh code reads JUPITER_PERPS_WALLET from the same shared variable map.
Runtime entry price variables
The refresh code should create/update entry price variables based on the currently open Jupiter Perps positions.
Only variables for positions that actually exist need to be created or updated. If no matching position exists, no variable should be created for that position.
Alarm expression behavior
Alarm target expressions and notes must be stored unresolved.
Target expressions and notes must be resolved against the current variable map each time they are used/evaluated.
This allows runtime variable updates to affect existing alarms without restarting the application.
If an alarm expression references a missing or null variable, log an error for that alarm evaluation and continue running.
A missing runtime variable must not stop the alarm application.
Refresh mechanism
Add a refresh trigger file mechanism using Java WatchService.
Watch the conf directory for:
jupiter-perps-alarm-var.refresh
When the trigger file is created or modified, refresh only the variable map entries related to Jupiter Perps entry prices.
After the refresh attempt, delete the trigger file.
If refresh fails, keep the previous variable values, log the error, delete the trigger file, and continue running.
If the trigger file already exists at startup, process it once.
Refresh must not reload alarm definitions or expect new/changed alarm rules.
Implementation
Use JupiterPerpsService.getOpenPositions(owner) to fetch positions.
Map tradedTokenMint to SOL, BTC, or ETH.
Map direction to LONG or SHORT.
Populate the matching *_ENTRY_PRICE variable from entryPrice.
Store variable values in the same format as config-loaded variables.
The alarm evaluation code should not need to know whether a variable came from the config file or runtime refresh.
Non-goals
No dynamic liquidation price
No alarm rule reload
No automatic trading detection
No AssetAZ/Evelyn integration
No UI changes
No trading or transaction signing
No source tracking for variables
No conflict detection between config variables and runtime variables
Acceptance criteria
{{JUPITER_PERPS_WALLET}} can be read from the config file.
Entry price variables can be used in alarm target expressions without being manually maintained in the config file.
Alarm target expressions and notes are resolved at evaluation/use time, not permanently during config load.
Runtime refresh can create or overwrite entry price variables in the shared variable map.
The trigger file is deleted after the refresh attempt.
If a position is missing, affected alarm evaluations log errors without stopping the application.
If Jupiter fetch fails, previous variable values are kept.
Project compiles.
### Description
Add runtime-updated Jupiter Perps entry price variables to the Jupiter Perps Alarm application.
The alarm config should no longer need manually maintained entry price constants. Instead, the application should be able to fetch open Jupiter Perps positions for a configured wallet and update the same variable map that is also populated by the config file.
### Variable model
* There is one shared variable map.
* Config loading writes variables into this map first.
* Runtime refresh may write new variables into the same map.
* Runtime refresh may overwrite variables that were originally loaded from config.
* There is no source tracking and no conflict rule.
* A variable that does not exist resolves to `null` / unresolved during alarm evaluation.
### Wallet configuration
* Add one config variable for the wallet address used for Jupiter Perps position lookup:
```text
{{JUPITER_PERPS_WALLET}} <wallet-address>
```
* The wallet address must come from the config file, not from hardcoded Java code.
* The runtime refresh code reads `JUPITER_PERPS_WALLET` from the same shared variable map.
### Runtime entry price variables
The refresh code should create/update entry price variables based on the currently open Jupiter Perps positions.
Expected variable names:
```text
{{SOL_LONG_ENTRY_PRICE}}
{{SOL_SHORT_ENTRY_PRICE}}
{{BTC_LONG_ENTRY_PRICE}}
{{BTC_SHORT_ENTRY_PRICE}}
{{ETH_LONG_ENTRY_PRICE}}
{{ETH_SHORT_ENTRY_PRICE}}
```
Only variables for positions that actually exist need to be created or updated. If no matching position exists, no variable should be created for that position.
### Alarm expression behavior
* Alarm target expressions and notes must be stored unresolved.
* Target expressions and notes must be resolved against the current variable map each time they are used/evaluated.
* This allows runtime variable updates to affect existing alarms without restarting the application.
* If an alarm expression references a missing or null variable, log an error for that alarm evaluation and continue running.
* A missing runtime variable must not stop the alarm application.
### Refresh mechanism
* Add a refresh trigger file mechanism using Java `WatchService`.
* Watch the `conf` directory for:
```text
jupiter-perps-alarm-var.refresh
```
* When the trigger file is created or modified, refresh only the variable map entries related to Jupiter Perps entry prices.
* After the refresh attempt, delete the trigger file.
* If refresh fails, keep the previous variable values, log the error, delete the trigger file, and continue running.
* If the trigger file already exists at startup, process it once.
* Refresh must not reload alarm definitions or expect new/changed alarm rules.
### Implementation
* Use `JupiterPerpsService.getOpenPositions(owner)` to fetch positions.
* Map `tradedTokenMint` to `SOL`, `BTC`, or `ETH`.
* Map `direction` to `LONG` or `SHORT`.
* Populate the matching `*_ENTRY_PRICE` variable from `entryPrice`.
* Store variable values in the same format as config-loaded variables.
* The alarm evaluation code should not need to know whether a variable came from the config file or runtime refresh.
### Non-goals
* No dynamic liquidation price
* No alarm rule reload
* No automatic trading detection
* No AssetAZ/Evelyn integration
* No UI changes
* No trading or transaction signing
* No source tracking for variables
* No conflict detection between config variables and runtime variables
### Acceptance criteria
* `{{JUPITER_PERPS_WALLET}}` can be read from the config file.
* Entry price variables can be used in alarm target expressions without being manually maintained in the config file.
* Alarm target expressions and notes are resolved at evaluation/use time, not permanently during config load.
* Runtime refresh can create or overwrite entry price variables in the shared variable map.
* Touching `conf/jupiter-perps-alarm-var.refresh` refreshes Jupiter Perps entry price variables.
* The trigger file is deleted after the refresh attempt.
* If a position is missing, affected alarm evaluations log errors without stopping the application.
* If Jupiter fetch fails, previous variable values are kept.
* Project compiles.
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.
Description
Add runtime-updated Jupiter Perps entry price variables to the Jupiter Perps Alarm application.
The alarm config should no longer need manually maintained entry price constants. Instead, the application should be able to fetch open Jupiter Perps positions for a configured wallet and update the same variable map that is also populated by the config file.
Variable model
null/ unresolved during alarm evaluation.Wallet configuration
JUPITER_PERPS_WALLETfrom the same shared variable map.Runtime entry price variables
The refresh code should create/update entry price variables based on the currently open Jupiter Perps positions.
Expected variable names:
Only variables for positions that actually exist need to be created or updated. If no matching position exists, no variable should be created for that position.
Alarm expression behavior
Refresh mechanism
WatchService.confdirectory for:Implementation
JupiterPerpsService.getOpenPositions(owner)to fetch positions.tradedTokenMinttoSOL,BTC, orETH.directiontoLONGorSHORT.*_ENTRY_PRICEvariable fromentryPrice.Non-goals
Acceptance criteria
{{JUPITER_PERPS_WALLET}}can be read from the config file.conf/jupiter-perps-alarm-var.refreshrefreshes Jupiter Perps entry price variables.