qishibo/AnotherRedisDesktopManager · warning

${this.$t('message.modify_failed')}, ${this.$t('message.valu

Error message

${this.$t('message.modify_failed')}, ${this.$t('message.value_not_exists')}

What it means

editLine() edits a list row without reordering it (#1082): it calls LINSERT key AFTER <before.value> <afterValue>, then LREMs the old value if the insert succeeded. LINSERT returns -1 when the pivot element is not found. A reply of 0/-1 here means the exact original value this UI row was based on no longer exists in the list, so the edit is refused to avoid silently duplicating or reordering rows.

Source

Thrown at src/components/contents/KeyContentList.vue:236

      const newLine = { value: afterValue };

      // edit line
      if (before.value) {
        // fix #1082, keep list order
        client.linsert(key, 'AFTER', before.value, afterValue).then((reply) => {
          if (reply > 0) {
            client.lrem(key, 1, before.value);
            // this.initShow(); // do not reinit, #786
            this.$set(this.listData, this.listData.indexOf(before), newLine);

            this.$message.success({
              message: this.$t('message.modify_success'),
              duration: 1000,
            });
          }
          // reply == -1, before.value has been removed
          else {
            this.$message.error({
              message: `${this.$t('message.modify_failed')}, ${this.$t('message.value_not_exists')}`,
              duration: 2000,
            });
          }
        }).catch((e) => { this.$message.error(e.message); });
      }
      // new line
      else {
        client.rpush(key, afterValue).then((reply) => {
          if (reply > 0) {
            // this.initShow(); // do not reinit, #786
            this.listData.push(newLine);
            this.total++;

            this.$message.success({
              message: this.$t('message.add_success'),
              duration: 1000,
            });

View on GitHub (pinned to c149855106)

Solutions

  1. Click reload/refresh on the key tab to resync the table with the server, then redo the edit on the fresh row
  2. Make sure no other client is concurrently mutating the key (check CLIENT LIST / MONITOR briefly), or coordinate edits
  3. If it keeps failing on a value you can see in the table, suspect encoding: copy the value via the copy-to-clipboard feature and compare bytes; verify the connection's charset settings match
  4. For queue-like keys being actively consumed, prefer editing during a quiet window or use a dedicated admin tool that re-reads before write

Example fix

// before: error toast, UI stays stale
else {
  this.$message.error({
    message: `${this.$t('message.modify_failed')}, ${this.$t('message.value_not_exists')}`,
    duration: 2000,
  });
}

// after: resync the view so the next edit works on fresh data
else {
  this.$message.error({
    message: `${this.$t('message.modify_failed')}, ${this.$t('message.value_not_exists')}`,
    duration: 2000,
  });
  this.resetTable();
  this.initShow();
}
Defensive patterns

Strategy: fallback

Validate before calling

// re-verify the pivot still exists before editing (Redis 6.2+ LPOS)
const idx = await client.lpos(key, before.value).catch(() => null);
if (idx === null) {
  this.$message.warning('Row changed on server — reloading');
  this.resetTable();
  this.initShow();
  return;
}
// proceed with LINSERT AFTER ...

Type guard

null

Try / catch

// LINSERT -1 is not an exception: treat it as a stale-state signal and resync
client.linsert(key, 'AFTER', before.value, afterValue)
  .then((reply) => {
    if (reply > 0) return client.lrem(key, 1, before.value);
    // pivot gone: fall back to a fresh read instead of leaving a stale table
    this.resetTable();
    return this.initShow();
  })
  .catch((e) => this.$message.error(e.message));

Prevention

When it happens

Trigger: LINSERT ... AFTER pivot returning -1: another client (CLI, another app window, worker) removed or modified the exact original value between when the table was rendered and when the user saved the edit; the row's value was binary-mangled in transit so the stored bytes differ from what the UI sends as pivot; the key was deleted and recreated with different contents.

Common situations: Two people/tabs editing the same list key; a background job consuming the list (LPUSH/LPOP queue) while a user edits an element shown in a stale table; editing a value that contains invisible bytes or encoding differences (latin1 vs utf8 client settings) so the pivot never matches; delayed edit after a long dialog open time.

Related errors

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