Dynamically adjust exchange polling delay with AutoConfig jobs

Gunbot's polling delay for an exchange is a critical setting that determines how frequently Gunbot fetches market data and updates. While this is set in config.js, AutoConfig provides a way to dynamically adjust this delay for an exchange if certain conditions are met. This is typically done using a top-level delay parameter within an AutoConfig job's action block, which then updates the corresponding exchange's delay in config.js.

Use the AutoConfig wizard

Nearly every option that follows can be set without editing files by hand.
Click the ⋮ (three-dots) menu ➜ AutoConfig, step through the wizard, and press Save; it will write a correct autoconfig.json for you.

The Exchange delay Setting in config.js

In your main Gunbot config.js file, each configured exchange has a delay parameter. This value, in milliseconds, dictates the pause Gunbot takes between cycles of fetching data (like order books, tickers, candles) for the pairs on that exchange.

// In config.js
"exchanges": {
  "binance": {
    "key": "...",
    "secret": "...",
    "delay": 5000, // Default polling delay for Binance: 5 seconds
    // ...
  }
}

A lower delay means more frequent updates but higher API usage. A higher delay reduces API load but means data is less fresh.

AutoConfig's delay Action Parameter

AutoConfig allows you to create jobs that, upon meeting filter conditions, can change this delay value for the job's target exchange directly in config.js. This is done by specifying a delay parameter at the top level of the AutoConfig job definition, alongside type, schedule, filters, etc.

Configuration Example:

Imagine you have a global variable experiencingApiIssues that gets set to true if your Gunbot instance (through some other mechanism or manual setting) detects frequent API errors from Binance. You can create an AutoConfig job to increase Binance's polling delay when this flag is true.

{
  "binanceDelayManager": {
    "enabled": true,
    // This job's primary purpose is to adjust exchange delay.
    "type": "changeDelay",
    "schedule": "*/1 * * * *", // Check every minute
    "pairs": {
      "exchange": "binance" // This job targets settings for 'binance'
    },
    "filters": {
      "apiIssueFlagIsActive": {
        "filterType": "variableExact",
        "experiencingApiIssues": true
      }
    },
    "delay": 15000 // User setting: New delay in ms (15 seconds)
                  // This will update config.exchanges.binance.delay
  }
}

In the binanceDelayManager job:

• "pairs": { "exchange": "binance" } defines that any exchange-level actions will target "binance".
• If the apiIssueFlagIsActive filter passes (i.e., the user defined global variable experiencingApiIssues is true):
  • The action delay: 15000 is triggered.
  • AutoConfig will modify your config.js file, changing config.exchanges.binance.delay to 15000.
• Gunbot will then typically start using this new delay for Binance after it reloads the configuration (AutoConfig usually triggers a config reload after making changes).

Reverting the Delay: You would typically need another AutoConfig job (or another filter set within the same job with inverted logic and a different delay value) to set the delay back to its normal value when experiencingApiIssues becomes false.

{
  "binanceDelayNormalizer": {
    "enabled": true,
    "type": "changeDelay",
    "schedule": "*/1 * * * *",
    "pairs": { "exchange": "binance" },
    "filters": {
      "apiIssuesResolved": {
        "filterType": "variableExact", // Or variableNotExist if the flag is deleted
        "experiencingApiIssues": false
      }
    },
    "delay": 5000 // Set delay back to 5 seconds
  }
}

Use Cases for Dynamic Delay Adjustment

1. API Rate Limit Management:

   • If Gunbot starts receiving API rate limit errors from an exchange, an AutoConfig job (reacting to a global variable set by an error detection mechanism or manually) could automatically increase the delay for that exchange to reduce request frequency.

2. Market-Dependent Update Frequency:

   • During extremely volatile periods (identified by filters or global variables), you might cautiously decrease the delay for faster updates on key pairs or exchanges. Caution: Decreasing delay too much is a common cause of API bans.
   • During very slow or sideways market periods, you could increase the delay to conserve resources.

3. Time-Based Adjustments:

   • Increase delay during known periods of low liquidity or exchange maintenance (e.g., late night for specific regional exchanges).
   • Decrease delay (cautiously) during specific trading sessions (e.g., London open, New York open).

4. System Load Management:

   • If your Gunbot instance is running on a resource-constrained machine and system load (tracked via external means and fed to a variable) becomes too high, AutoConfig could increase delays for less critical exchanges.

Important Considerations

• Milliseconds: The delay value is specified in milliseconds (e.g., 5000 for 5 seconds).
• Impact on Trading: Changing the polling delay affects how quickly Gunbot reacts to market changes. A very high delay can cause strategies to miss entry/exit signals. A very low delay can lead to API rate limiting or bans.
• Global Effect for the Exchange: The AutoConfig delay action changes the delay for all pairs running on that exchange, as it modifies the exchange-level setting in config.js.
• Dynamic Values: The value for the delay action can also be a string evaluated as JavaScript (if it starts with a leading space), allowing dynamic calculation based on this.variables, etc.

  "delay": " (this.variables.apiErrorCount > 5 ? 20000 : 5000) "
• Reloading config.js: AutoConfig writes these changes to config.js, and Gunbot usually reloads its configuration shortly after to apply such changes. However, the exact timing and whether all aspects of a delay change take effect without a full restart can depend on the Gunbot version.

Dynamically adjusting exchange polling delays via AutoConfig is an advanced technique that can help make your Gunbot setup more robust against API issues or more adaptive to changing market tempos. However, it requires careful planning and consideration of the potential impacts on trading performance and API usage.