qishibo/AnotherRedisDesktopManager · warning

this.$t('message.delete_failed')

Error message

this.$t('message.delete_failed')

What it means

After DEL on a tree node in KeyListVirtualTree.vue, Redis replies with the number of keys actually removed; reply != 1 means the key did not exist server-side anymore (expired or deleted elsewhere between view and click), so the localized delete_failed toast is shown. The DEL command itself succeeded - it simply removed nothing.

Source

Thrown at src/components/KeyListVirtualTree.vue:235

        // del single key["delete" in the key right menu]
        case 'delete': {
          // del batch instead of single when multi operating
          if (this.multiOperating) {
            return this.deleteBatch();
          }

          const keyBuffer = Buffer.from(this.rightClickNode.data.nameBuffer.data);

          this.client.del(keyBuffer).then((reply) => {
            if (reply == 1) {
              this.$message.success({
                message: this.$t('message.delete_success'),
                duration: 1000,
              });

              this.$bus.$emit('refreshKeyList', this.client, keyBuffer, 'del');
            } else {
              this.$message.error(this.$t('message.delete_failed'));
            }
          }).catch((e) => { this.$message.error(e.message); });
          break;
        }
        // select multiple
        case 'multiple_select': {
          this.showMultiSelect();
          break;
        }
        // open key in new tab
        case 'open': {
          this.clickKey(Buffer.from(this.rightClickNode.data.nameBuffer.data), true);
          break;
        }
        // delete whole folder
        case 'delete_folder': {
          const rule = { pattern: [this.rightClickNode.data.fullName] };
          this.$bus.$emit('openDelBatch', this.client, this.config.connectionName, rule);

View on GitHub (pinned to c149855106)

Solutions

1. Refresh the key list/tree - the stale node disappears.
2. Optionally confirm with EXISTS in the CLI tab if unsure whether the key is really gone.
3. No data risk: if the key still exists after refresh, delete it again from the refreshed list.

// optional existence check right before delete
const exists = await client.exists(keyBuffer);
if (!exists) { removeNodeFromTree(); return; }

const wasDeleted = (reply) => reply === 1; // DEL returns the count actually removed

this.client.del(keyBuffer).then((reply) => {
  if (wasDeleted(reply)) success();
  else {
    // key vanished server-side: treat as stale view, not as an error
    this.$message.warning('Key already gone - refreshing');
    this.$bus.$emit('refreshKeyList', this.client);
  }
});

When it happens

Trigger: Key expired (had a TTL) while the tree node was still visible; the key was deleted by another client or a second GUI session; stale tree node left after a missed refresh.

Common situations: Two sessions open on the same DB; short-TTL keys disappearing during browsing; cluster failover repartitioning keys away from the scanned node.

Related errors

• ${this.redisKey} ${this.$t('message.delete_failed')}
• e.message
• e.message
• Rename Error: ${e.message}
• this.$t('message.delete_failed')

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