qishibo/AnotherRedisDesktopManager · error

this.$t('message.test_connection_timeout')

Error message

this.$t('message.test_connection_timeout')

What it means

testConnection arms a fixed 5-second setTimeout that calls finishTest(false, timeout-message) if the ioredis client has not reached ready + PING by then; cleanupTestClient then disconnects the still-pending attempt. A timeout (rather than a fast rejection) means packets are being silently dropped or the SSH/TLS handshake is slower than the fixed 5000ms budget.

Source

Thrown at src/components/NewConnectionDialog.vue:440

        this.$message.error(message || this.$t('message.test_connection_failed'));
      }
    },
    testConnection() {
      if (this.testing) {
        return;
      }

      const config = this.getConnectionConfig();
      if (!config) {
        return;
      }

      this.testing = true;
      this.testClient = null;

      // show timeout message after N seconds
      this.testTimer = setTimeout(() => {
        this.finishTest(false, this.$t('message.test_connection_timeout'));
      }, 5000);

      const clientPromise = config.sshOptions
        ? redisClient.createSSHConnection(
          config.sshOptions, config.host, config.port, config.auth, config,
        )
        : redisClient.createConnection(
          config.host, config.port, config.auth, config,
        );

      clientPromise.then((client) => {
        this.testClient = client;
        client.options.retryStrategy = () => false;

        // Already finished (timeout/cancel) while creating connection.
        if (!this.testing) {
          this.cleanupTestClient();
          return;

View on GitHub (pinned to c149855106)

Solutions

  1. Check the firewall/security group allows the client to reach the port (telnet host port / tcping)
  2. Verify the VPN/network path and DNS resolution from this machine
  3. Retry once - transient network hiccups are a common cause
  4. If the path is legitimately slow (multi-hop SSH, high-latency TLS), raise the 5000ms budget in testConnection's testTimer

Example fix

// before
this.testTimer = setTimeout(() => {
  this.finishTest(false, this.$t('message.test_connection_timeout'));
}, 5000);

// after - budget scales with SSH/TLS overhead
const budget = config.sshOptions || config.sslOptions ? 15000 : 5000;
this.testTimer = setTimeout(() => {
  this.finishTest(false, this.$t('message.test_connection_timeout'));
}, budget);
Defensive patterns

Strategy: retry

Validate before calling

// distinguish 'slow' from 'unreachable' before the 5s test:
// a TCP probe that also times out means dropped packets, not a slow handshake
const reachable = await tcpReachable(host, port, 3000);
if (!reachable) {
  showError('host unreachable - check firewall/security group');
  return;
}

Try / catch

// race the connection against a timer, and retry transient timeouts once
await Promise.race([
  connectWithPing(config),
  new Promise((_, rej) => setTimeout(() => rej(new Error('timeout')), 5000)),
]).catch(async (e) => {
  if (e.message === 'timeout' && !(await retryOnce())) {
    showError('connection timeout - likely firewall or routing');
  }
});

Prevention

When it happens

Trigger: Firewall/security group dropping SYN packets to the port (no RST, so no ECONNREFUSED), unroutable host (wrong VPC/VPN), DNS resolution hang, slow SSH tunnel establishment, or a TLS handshake to a dead endpoint - any case where neither 'ready' nor 'error' fires within 5000ms.

Common situations: Cloud security groups not allowing the client IP, VPN down while connecting to internal Redis, high-latency SSH bastion hops, NAT without port forwarding.

Understand the failure class

Related errors


AI-assisted analysis of qishibo/AnotherRedisDesktopManager@c149855106 (2026-08-22). Data as JSON: /api/errors/6e093185a14a7b07. Report an issue: GitHub.