Preamble¶
DSH (DeepSeek Harness) adopts a plugin-based architecture, aiming to modularize functionality to adapt to different workflow scenarios. When developing and debugging LLM applications, it is common to encounter request failures caused by network instability or rate limiting (for example, an HTTP 429 status code). The dsh-llm-error-retry plugin intercepts error events, sleeps according to configured rules, and then retries, thereby reducing manual intervention and improving the stability of automated workflows.
Plugin Overview¶
- Name: dsh-llm-error-retry
- Positioning: DSH Profile Bundle plugin
- Owner: liaoyuqing
- Category: Workflow
- License: MIT
Installation and Activation¶
Installing this plugin requires DSH’s package management command. Make sure your web profile is running.
dsh plugin --profile web add github:liaoyuqing/dsh-llm-error-retry
After installation, you need to restart that profile to complete the assembly at the bundle layer. After refreshing the GUI page, find Settings → LLM Error Retry in the lower-left corner to see the configuration section. You can also operate through the fallback configuration page at <http://127.0.0.1:3080/llm-error-retry>.
Core Features¶
This plugin provides the following core capabilities:
- Multi-form error matching: Supports matching errors by HTTP status code, machine code (such as
RATE_LIMIT), or returned field=value (such ascode=insufficient_quota). This covers common scenarios, including adapter formats that flatten the status code into the message. - Independent rule configuration: Each rule can independently configure the sleep duration (
delayMs) and maximum retry count (maxRetries). - GUI real-time editing: Provides a graphical interface to edit rules in real time. Changes take effect immediately after saving and persist across restarts.
- Session display: The retry process is displayed in the session box as a native retry card, showing current progress (such as “Attempt N/M · Sleeping Xs”). It can be interrupted or stopped by the user during the sleep period, and the card will be displayed as canceled.
Typical Usage¶
When configuring rules, the JSON fields have the following meanings:
{
"rules": [
{
"code": "429",
"delayMs": 60000,
"maxRetries": 10
}
]
}
With this configuration, when a model request returns a 429 error, the system will sleep for 60 seconds and then attempt to resend the request, retrying up to 10 times. If the retry count is exhausted, the error will be reported as is. Supported match examples also include 500, RATE_LIMIT, and code=insufficient_quota.
Notes¶
During development or deployment, pay attention to the following points:
- Zero dependencies and no build: This package has no build scripts and zero runtime dependencies. Installation essentially means a pnpm dependency and automatic registration through the
dsh.bundledeclaration. - File naming rules: Any code changes on the host side (such as
host.v7.mjs) must be made under a new file name (for example,host.v8.mjs), and the exports path inpackage.jsonas well as the name incordis.patch.ymlmust be updated accordingly, because DSH’s HMR mechanism does not reload ESM modules at the same path. - HTTP response limitation: Host HTTP responses must never include
Content-Lengthon their own. If you use a gzip middleware in thewebprofile, manually settingContent-Lengthcan conflict with the actual compressed length and cause the browser to discard the response body. - Data storage: User configuration must never be written into the package directory (pnpm store upgrades may replace the package contents). The data directory is fixed at
~/.dsh/llm-error-retry/, including the rule configuration file (rules.json) and the runtime snapshot (status.json).
Conclusion¶
dsh-llm-error-retry solves common transient failures in LLM requests through rule-based retry strategies. Developers can quickly adjust the strategy in the GUI or define more complex retry logic in the configuration file. Related documentation and source code can be found in the GitHub repository.