Add dynamic Jupiter Perps entry price variables to alarm config #20

New Issue

2026-06-27T10:47:39+02:00

minimons commented

2026-06-27 10:47:39 +02:00

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:

{{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:

{{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:

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.

### 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.

minimons added the enhancement label 2026-06-27 10:47:39 +02:00

minimons self-assigned this 2026-06-27 10:47:39 +02:00

minimons added this to the AssetAZ project 2026-06-27 10:47:39 +02:00

minimons moved this to In Progress in AssetAZ on 2026-06-27 10:52:33 +02:00

minimons closed this issue

2026-06-28 23:29:09 +02:00

minimons moved this to Done in AssetAZ on 2026-06-28 23:29:52 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: r35157/com_r35157_nenjim-hubd-impl_ref#20