Add runtime-updated Jupiter Perps liquidation price variables to the Jupiter Perps Alarm application.
The alarm config should no longer need manually maintained liquidation price constants. Instead, the application should fetch open Jupiter Perps positions for the configured wallet and update liquidation price variables in the shared variable map.
This should work the same way as the existing dynamic entry price variables.
Runtime liquidation price variables
The refresh code should create/update liquidation 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.
Required changes
Use JupiterPerpsService.getOpenPositions(owner) through the existing refresh flow.
Map tradedTokenMint to SOL, BTC, or ETH.
Map direction to LONG or SHORT.
Populate the matching *_LIQ_PRICE variable from liquidationPrice.
Remove stale liquidation price variables before inserting refreshed values, but only after a successful fetch.
Keep the existing entry price variable refresh behavior unchanged.
Non-goals
No liquidation price calculation in this issue.
No changes to alarm rule parsing.
No alarm rule reload.
No AssetAZ/Evelyn integration.
No trading or transaction signing.
Prerequisites
This issue depends on liquidationPrice being available in JupiterPerpsPosition.
Acceptance criteria
Liquidation price variables can be used in alarm target expressions without being manually maintained in the config file.
Touching conf/jupiter-perps-alarm-var.refresh refreshes both entry price and liquidation price variables.
Existing *_ENTRY_PRICE refresh behavior still works.
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 liquidation price variables to the Jupiter Perps Alarm application.
The alarm config should no longer need manually maintained liquidation price constants. Instead, the application should fetch open Jupiter Perps positions for the configured wallet and update liquidation price variables in the shared variable map.
This should work the same way as the existing dynamic entry price variables.
### Runtime liquidation price variables
The refresh code should create/update liquidation price variables based on the currently open Jupiter Perps positions.
Expected variable names:
```text
{{SOL_LONG_LIQ_PRICE}}
{{SOL_SHORT_LIQ_PRICE}}
{{BTC_LONG_LIQ_PRICE}}
{{BTC_SHORT_LIQ_PRICE}}
{{ETH_LONG_LIQ_PRICE}}
{{ETH_SHORT_LIQ_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.
### Required changes
* Use `JupiterPerpsService.getOpenPositions(owner)` through the existing refresh flow.
* Map `tradedTokenMint` to `SOL`, `BTC`, or `ETH`.
* Map `direction` to `LONG` or `SHORT`.
* Populate the matching `*_LIQ_PRICE` variable from `liquidationPrice`.
* Remove stale liquidation price variables before inserting refreshed values, but only after a successful fetch.
* Keep the existing entry price variable refresh behavior unchanged.
### Non-goals
* No liquidation price calculation in this issue.
* No changes to alarm rule parsing.
* No alarm rule reload.
* No AssetAZ/Evelyn integration.
* No trading or transaction signing.
### Prerequisites
This issue depends on `liquidationPrice` being available in `JupiterPerpsPosition`.
### Acceptance criteria
* Liquidation price variables can be used in alarm target expressions without being manually maintained in the config file.
* Touching `conf/jupiter-perps-alarm-var.refresh` refreshes both entry price and liquidation price variables.
* Existing `*_ENTRY_PRICE` refresh behavior still works.
* 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.
There is a problem here. The refresher only pulls information to be able to update the entry price.
Therefore will the liquidation price never get updated only by creating the jupiter-perps-alarm-var.refresh trigger file will the liquidation price get updated.
Also take into consideration that pulling data to be able to update the liquidation price is not received as as stream. Only the current price is so it might be expensive. That is why I prefer to work on #28 first, as the lookups are quite slow now.
There is a problem here. The refresher only pulls information to be able to update the `entry price`.
Therefore will the `liquidation price` never get updated only by creating the `jupiter-perps-alarm-var.refresh` trigger file will the `liquidation price` get updated.
Also take into consideration that pulling data to be able to update the `liquidation price` is not received as as stream. Only the current price is so it might be expensive. That is why I prefer to work on #28 first, as the lookups are quite slow now.
The fastest and cheapest solution is to run the existing refresher periodically from a scheduled background task.
This ensures that liquidation price is updated periodically, in addition to the refresh performed at application startup and when the existing trigger file (jupiter-perps-alarm-var.refresh) is created.
The fastest and cheapest solution is to run the existing refresher periodically from a scheduled background task.
This ensures that `liquidation price` is updated periodically, in addition to the refresh performed at application startup and when the existing trigger file (`jupiter-perps-alarm-var.refresh`) is created.
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 liquidation price variables to the Jupiter Perps Alarm application.
The alarm config should no longer need manually maintained liquidation price constants. Instead, the application should fetch open Jupiter Perps positions for the configured wallet and update liquidation price variables in the shared variable map.
This should work the same way as the existing dynamic entry price variables.
Runtime liquidation price variables
The refresh code should create/update liquidation 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.
Required changes
JupiterPerpsService.getOpenPositions(owner)through the existing refresh flow.tradedTokenMinttoSOL,BTC, orETH.directiontoLONGorSHORT.*_LIQ_PRICEvariable fromliquidationPrice.Non-goals
Prerequisites
This issue depends on
liquidationPricebeing available inJupiterPerpsPosition.Acceptance criteria
conf/jupiter-perps-alarm-var.refreshrefreshes both entry price and liquidation price variables.*_ENTRY_PRICErefresh behavior still works.There is a problem here. The refresher only pulls information to be able to update the
entry price.Therefore will the
liquidation pricenever get updated only by creating thejupiter-perps-alarm-var.refreshtrigger file will theliquidation priceget updated.Also take into consideration that pulling data to be able to update the
liquidation priceis not received as as stream. Only the current price is so it might be expensive. That is why I prefer to work on #28 first, as the lookups are quite slow now.The fastest and cheapest solution is to run the existing refresher periodically from a scheduled background task.
This ensures that
liquidation priceis updated periodically, in addition to the refresh performed at application startup and when the existing trigger file (jupiter-perps-alarm-var.refresh) is created.