qishibo/AnotherRedisDesktopManager · error

e.message

Error message

e.message

What it means

Error toast fed by the 'error' event of the ioredis HSCAN stream (hscanBufferStream) in KeyContentHash.vue:235. The component listens on the scanStream EventEmitter; ioredis emits 'error' when a cursor round-trip fails — typically a dropped/closed connection mid-iteration, a READONLY reply from a replica, or WRONGTYPE because the key stopped being a hash. The handler also resets loadingIcon and disables 'load more', so the list stays partially loaded.

Source

Thrown at src/components/contents/KeyContentHash.vue:235

        // init hash field ttls
        this.initTTL(hashData, listLength);

        if (this.oneTimeListLength >= this.pageSize) {
          this.scanStream.pause();
          this.loadingIcon = '';
        }
      });

      this.scanStream.on('end', () => {
        this.loadingIcon = '';
        this.loadMoreDisable = true;
      });

      this.scanStream.on('error', (e) => {
        this.loadingIcon = '';
        this.loadMoreDisable = true;
        this.$message.error(e.message);
      });
    },
    getScanMatch() {
      return this.filterValue ? `*${this.filterValue}*` : '*';
    },
    openDialog() {
      this.$nextTick(() => {
        this.$refs.formatViewer.autoFormat();
      });
    },
    showEditDialog(row) {
      this.editLineItem = this.$util.cloneObjWithBuff(row);
      this.beforeEditItem = row;
      this.editDialog = true;
    },
    dumpCommand(item) {
      const lines = item ? [item] : this.hashData;
      const params = lines.map(line => `${this.$util.bufToQuotation(line.key)} ${

View on GitHub (pinned to c149855106)

Solutions

  1. Check whether the rest of the app also lost the connection (left tree, other tabs); reconnect and reload the key if so
  2. If only this key fails, verify its type still shows 'hash' in the header — another client may have replaced it (WRONGTYPE)
  3. Reduce the amount fetched per page or narrow the filter so fewer cursor round-trips are needed
  4. For tunnels/VPN, increase keepalive timeouts in the connection config before scanning big hashes

Example fix

// before
this.scanStream.on('error', (e) => {
  this.loadingIcon = '';
  this.loadMoreDisable = true;
  this.$message.error(e.message);
});

// after: allow reconnect + manual retry instead of permanently disabling pagination
this.scanStream.on('error', (e) => {
  this.loadingIcon = '';
  this.loadMoreDisable = !/closed|timed out/i.test(e.message);
  this.scanStream = null; // force a fresh stream on next loadMore
  this.$message.error(e.message);
});
Defensive patterns

Strategy: try-catch

Validate before calling

// start the scan only on a healthy connection
if (this.client.status !== 'ready') {
  this.$message.error(`connection not ready (${this.client.status})`);
  return;
}

Try / catch

this.scanStream.on('error', (e) => {
  this.loadingIcon = '';
  this.scanStream = null;               // force fresh stream on next loadMore
  this.loadMoreDisable = /WRONGTYPE/.test(e.message); // only hard-fail on shape errors
  this.$message.error(e.message);
});

Prevention

When it happens

Trigger: hscanBufferStream emits error when: the TCP connection dies between SCAN cursors ('Connection is closed'); Redis failover/redirect happens during iteration; the key is DELeted and recreated as a string/zset so the next HSCAN returns WRONGTYPE; maxmemory/OOM policies reject subsequent SCAN-family reads; or the sentinel/cluster topology changes under the stream.

Common situations: Laptop sleep/resume while a large hash is paging in; SSH tunnel (tunnel-ssh) timing out during a long scan; scanning a hot key while a migration rewrites it; paging through millions of hash fields over a flaky VPN.

Related errors


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