Introduction

In DeepSeek Harness (DSH), a single model request may pass through a relay, reverse proxy, API gateway, or forwarding service. Temporary disconnections, 5xx errors, rate limiting, and timeouts can all interrupt agent rounds or long-running tasks.

dsh-reconnect is a Host-side plugin for DeepSeek Harness (DSH). It takes over recoverable failures after the Provider’s normal/always strategies and resends the same request according to the plugin’s own policy.

What is it

The positioning of dsh-reconnect is:

Safe model-request retry for DeepSeek Harness with exponential backoff, relay/proxy failure recovery, and a unified settings panel.

Verified Information:

  • Maintainer: MistRain-1
  • Version: 2.0.0
  • License: MIT
  • Location: DSH Host plugin
  • Dependencies: DSH Host, agent/request-error waterfall event, Host settings service

It primarily solves the problem of “the same model request failing due to temporary failures,” avoiding terminating the current agent step directly due to temporary network or service anomalies.

Core Features

Listening and Taking Over

dsh-reconnect listens to the DSH agent/request-error waterfall event.

After the built-in normal Provider retry strategy gives up, or when the Provider always strategy defers recovery to the downstream, this plugin resends the same request based on its own strategy.

Retry Scope

Scenario Behavior
Temporary failures such as EMPTY_RESPONSE, RATE_LIMIT, SERVER, STREAM_CLOSED, TIMEOUT, TRANSPORT, etc. Retry according to plugin strategy
Model missing or not configured Continue retry, wait for model or account configuration to recover
QUOTA Default no retry; retry after enabling retryQuota: true
Unknown errors Default infinite retry; use unknownMaxRetries limit after disabling retryUnknown
Tool execution errors, parameter errors, unknown tools, authentication, credentials, context overflow, abort, etc. Never retry, and end the step immediately

Exponential Backoff

The plugin uses exponential backoff:

1s -> 2s -> 4s -> ...

The default local backoff limit is 60s.

maxDelayMs only limits the local exponential backoff delay; it does not limit the Provider Retry-After, nor the total retry duration.

If maxDelayMs is invalid or missing, it falls back to the default value 60000.

Provider Retry-After

When a positive providerRetryAfterMs or Provider Retry-After header exists, the plugin respects this minimum wait.

It is the minimum wait given by the Provider side and is not limited by the local maxDelayMs exponential backoff limit.

Events and Cleanup

The plugin emits the standard llm/retry event for Harness to display retry count and countdown in the dialogue UI.

Active waits are stopped and cleaned up in the following cases:

  • Current round aborted
  • Plugin stopped
  • Plugin hot reload

Installation and Enablement

Getting the Plugin Package

A verified way to obtain it is Git clone:

git clone https://github.com/MistRain-1/dsh-reconnect.git "$HOME/dsh-reconnect"

The plugin package can also be obtained via GitHub Web Download or terminal ZIP download.

Registering the Plugin

Register the plugin package to the DSH Cordis composition:

- insert:
    - id: reconnect
      name: dsh-reconnect

A restart of DSH is required after installing the persistent plugin package.

Plugin configuration changes can take effect immediately without needing a restart.

Typical Usage

Using the Settings Card

Open:

Settings → Plugin configuration

Find the ReConnect plugin card to configure:

  • Max wait per attempt: Choose 1/2/5/10/30/60/120 seconds, or a custom value
  • Retry on quota: Default off
  • Retry unknown errors indefinitely: Default on
  • Max retries for unknown errors: Default 3

Errors where the model is missing or not configured are not limited by the unknown error retry limit.

Using YAML Configuration

It can be configured in Cordis row config:

- insert:
    - id: reconnect
      name: dsh-reconnect
      config:
        maxDelayMs: 15000
        retryQuota: false
        retryUnknown: true

In the example:

  • maxDelayMs: 15000 indicates the local exponential backoff limit is 15000ms
  • retryQuota: false indicates QUOTA will not retry by default
  • retryUnknown: true indicates unknown errors will retry indefinitely by default

The local backoff sequence corresponding to maxDelayMs: 15000 is roughly:

1s -> 2s -> 4s -> 8s -> 15s -> 15s...

A positive Retry-After on the Provider side still takes precedence.

Applicable Scenarios and Notes

Suitable for:

  • Unstable relay nodes
  • Occasional failures of reverse proxy, API gateway, or forwarding service
  • Connection reset, disconnection, or incomplete responses
  • Temporary provider failure, server 5xx, rate limiting, or timeouts
  • Wanting long-running tasks to continue after short-term provider or network failures

Notes to consider:

  • QUOTA does not retry by default. When balance is insufficient or quota is exhausted, it will not wait indefinitely.
  • Unknown errors retry indefinitely by default. After disabling retryUnknown, unknownMaxRetries defaults to 3 and is only used for consecutive unknown failures within the same model step.
  • maxDelayMs does not limit the Provider Retry-After nor the total retry duration.
  • Errors such as tool execution errors, parameter errors, unknown tools, authentication, credentials, context overflow, abort, etc., will not be retried and will immediately end the step.
  • The plugin runs with the permissions of the current dsh process; the source code and license should be checked before installation.
  • The client only provides a unified settings card and does not read credentials.

Resources

  • GitHub: https://github.com/MistRain-1/dsh-reconnect