qishibo/AnotherRedisDesktopManager · error

Stream On Error: ${e.message}

Error message

Stream On Error: ${e.message}

What it means

The catch-all branch of KeyList.vue's SCAN stream 'error' handler: any stream failure that does not match the known SCAN-disabled signatures prints 'Stream On Error: <e.message>' and then emits closeConnection 50 ms later, tearing down the session. The underlying cause is in e.message - typically a dropped connection mid-scan or a server error reply.

Source

Thrown at src/components/KeyList.vue:195

          }
        });

        stream.on('error', (e) => {
          this.resetSearchStatus();

          // scan command disabled, other functions may be used normally
          if (
            (e.message.includes('unknown command') && e.message.includes('scan'))
            || e.message.includes("command 'SCAN' is not allowed")
          ) {
            return this.$message.error({
              message: this.$t('message.scan_disabled'),
              duration: 1500,
            });
          }

          // other errors
          this.$message.error({
            message: `Stream On Error: ${e.message}`,
            duration: 1500,
          });

          setTimeout(() => {
            this.$bus.$emit('closeConnection');
          }, 50);
        });

        stream.on('end', () => {
          // all nodes scan finished(cusor back to 0)
          if (--this.scanningCount <= 0) {
            this.scanMoreDisabled = true;
            this.resetSearchStatus();
          }
        });
      });
    },

View on GitHub (pinned to c149855106)

Solutions

  1. Read the e.message portion of the toast to identify the real cause (connection reset, server error, etc.).
  2. Reconnect and rescan with a narrower match pattern so the scan finishes faster.
  3. Stabilize the transport for long scans: SSH keepalives, higher proxy idle timeouts, stable VPN.
Defensive patterns

Strategy: try-catch

Validate before calling

// cheap liveness check before starting a long scan
const alive = await client.ping().then(() => true).catch(() => false);
if (!alive) return reconnectFirst();

Type guard

const isFatalStreamError = (e) => !((e.message.includes('unknown command') && e.message.includes('scan')) || e.message.includes("command 'SCAN' is not allowed"));

Try / catch

stream.on('error', (e) => {
  if (isFatalStreamError(e)) {
    this.$message.error(`Stream On Error: ${e.message}`);
    this.$bus.$emit('closeConnection'); // app behavior: session torn down
  }
});

Prevention

When it happens

Trigger: Connection lost while SCAN is streaming a large keyspace (server restart, network blip, SSH tunnel collapse); Redis failover during a scan; proxy or load balancer idle-timeout killing the long-lived scan connection; server returning an error reply mid-cursor.

Common situations: Scanning a database with millions of keys over VPN; scan running during a maintenance restart; aggressive proxy timeouts in front of Redis.

Related errors


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