What causes "e.message" in qishibo/AnotherRedisDesktopManager?

Re-check the key type (TYPE key) and reload the tab before saving

qishibo/AnotherRedisDesktopManager · error

e.message

Error message

e.message

What it means

Promise catch for the SET that persists edited string content; it toasts the raw error message. Typical causes: WRONGTYPE (the key's type changed since the viewer opened), WRONGPASS/NOAUTH, READONLY (writing to a replica), OOM (maxmemory with noeviction), or the connection dropping mid-save.

Source

Thrown at src/components/contents/KeyContentString.vue:69

        content,
      ).then((reply) => {
        if (reply === 'OK') {
          // for compatibility, use expire instead of setex
          this.setTTL();
          this.initShow();

          this.$message.success({
            message: this.$t('message.modify_success'),
            duration: 1000,
          });
        } else {
          this.$message.error({
            message: this.$t('message.modify_failed'),
            duration: 1000,
          });
        }
      }).catch((e) => {
        this.$message.error(e.message);
      });
    },
    setTTL() {
      const ttl = parseInt(this.$parent.$parent.$refs.keyHeader.keyTTL);

      if (ttl > 0) {
        this.client.expire(this.redisKey, ttl).catch((e) => {
          this.$message.error(`Expire Error: ${e.message}`);
        }).then((reply) => {});
      }
    },
    initShortcut() {
      this.$shortcut.bind('ctrl+s, ⌘+s', this.hotKeyScope, () => {
        // make input blur to fill the new value
        // this.$refs.saveBtn.$el.focus();
        this.execSave();

        return false;

View on GitHub (pinned to c149855106)

Solutions

Re-check the key type (TYPE key) and reload the tab before saving
Write to the master, not a replica
Free memory or adjust maxmemory-policy, then retry
Verify the connection's auth/ACL grants the set command

Defensive patterns

Strategy: try-catch

Validate before calling

// re-validate type right before saving an edited string
const type = await client.type(key);
if (type !== 'string') {
  showError(`key changed to ${type} - reload before saving`);
  return;
}

Try / catch

// classify the failure so the user gets an actionable message
try {
  await client.set(key, value);
} catch (e) {
  if (e.message.startsWith('WRONGTYPE')) promptReload();
  else if (e.message.startsWith('READONLY')) promptSwitchToMaster();
  else if (e.message.includes('OOM')) promptMemoryCheck();
  else showError(e.message);
}

Prevention

Reload the key before saving if other tools may have modified it
Never point write-heavy GUI work at a replica
Watch maxmemory: noeviction turns saves into OOM errors under pressure

When it happens

Trigger: Editing a string whose type was changed concurrently (recreated as a hash elsewhere), saving to a read-only replica, server at maxmemory with noeviction policy, ACL user lacking the set command, connection reset during save.

Common situations: Two tools editing the same key, connected to a replica for writes, memory-full production instances, fine-grained ACLs.

Related errors

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