qishibo/AnotherRedisDesktopManager · warning

this.$t('message.delete_failed')

Error message

this.$t('message.delete_failed')

What it means

Not a thrown error: the non-cluster DEL (client.del(chunked)) resolved, but the reply was 0 — none of the submitted keys existed at delete time. Keys can vanish between the SCAN and the DEL (TTL expiry, another client deleting), or the wrong DB is targeted. The app routes this to deleteFailed with the localized 'delete failed' message.

Source

Thrown at src/components/DeleteBatch.vue:159

        for (let i = 0; i < total; i++) {
          chunked.push(keys[i].key);

          // del 5000 keys one time
          if (chunked.length >= 5000) {
            delPromise = this.client.del(chunked);
            chunked = [];
          }
        }

        if (chunked.length) {
          delPromise = this.client.del(chunked);
        }
        // use final promise
        delPromise.then((reply) => {
          if (reply > 0) {
            this.afterDelete();
          } else {
            this.deleteFailed(this.$t('message.delete_failed'));
          }
        }).catch((e) => {
          this.deleteFailed(e.message);
        });
      }

      // cluster, one key per time instead of batch
      else {
        for (let i = 0; i < total; i++) {
          delPromise = this.client.del(keys[i].key);
          delPromise.catch((e) => {});
        }

        // use final promise
        delPromise.then((reply) => {
          if (reply == 1) {
            this.afterDelete();
          } else {

View on GitHub (pinned to c149855106)

Solutions

1. Treat a 0 reply as 'already gone' (info-level) instead of a hard failure
2. Re-scan to refresh the key list right before deleting
3. Confirm the correct DB/connection is selected for both scan and delete
4. Check TTLs on the target keys before batch-deleting volatile keys

Example fix

// before
delPromise.then((reply) => {
  if (reply > 0) { this.afterDelete(); }
  else { this.deleteFailed(this.$t('message.delete_failed')); }
});

// after
delPromise.then((reply) => {
  if (reply > 0) { this.afterDelete(); }
  else {
    // keys vanished before DEL ran: end state is what the user wanted
    this.$message.info(this.$t('message.already_deleted'));
    this.afterDelete();
  }
});

// prune keys that no longer exist before issuing DEL
const existing = await this.client.exists(...chunked);
if (existing === 0) {
  this.afterDelete();
  return;
}

When it happens

Trigger: Keys with short TTLs expiring while the scan dialog is open; another session or CLI deleting the same keys; keys scanned from a different DB than the DEL runs against.

Common situations: Cleanup racing with expiring sessions/locks, two operators cleaning the same keyspace, tools scanning db0 while the client switched DBs.

Related errors

• e.message
• msg
• Delete Batch Stream On Error: ${e.message}
• You are in readonly mode! Unable to execute write command!
• this.$t('message.delete_failed')

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