qishibo/AnotherRedisDesktopManager · warning
this.$t('message.key_not_exists')
Error message
this.$t('message.key_not_exists') What it means
refreshContent() runs EXISTS on the selected key; a reply of 0 means the key no longer exists on the server, and a 1-second toast is shown instead of initializing the viewer (this.$refs.keyContent.initShow is skipped). The key vanished between selection and refresh - TTL expiry, deletion by another client, RENAME, or eviction under maxmemory.
Source
Thrown at src/components/KeyDetail.vue:95
'ReJSON-RL': 'KeyContentReJson',
json: 'KeyContentReJson', // upstash
'tair-json': 'KeyContentReJson', // tair
};
if (map[keyType]) {
return map[keyType];
}
// type not support, such as bf
this.$message.error(this.$t('message.key_type_not_support'));
return '';
},
refreshContent() {
this.client.exists(this.redisKey).then((reply) => {
if (reply == 0) {
// clear interval if auto refresh opened
// this.$refs.keyHeader.removeInterval();
return this.$message.error({
message: this.$t('message.key_not_exists'),
duration: 1000,
});
}
this.$refs.keyContent && this.$refs.keyContent.initShow();
}).catch((e) => {
this.$message.error(`Exists Error: ${e.message}`);
});
},
dumpCommand() {
this.$refs.keyContent && this.$refs.keyContent.dumpCommand();
},
},
};
</script>
<style type="text/css">View on GitHub (pinned to c149855106)
Solutions
- Refresh the key list - the key disappears from the tree and the toast stops
- If the key should still exist, check TTL and eviction: TTL key, CONFIG GET maxmemory-policy
- Recreate the key if it was deleted unintentionally
Defensive patterns
Strategy: validation
Validate before calling
// check existence right before acting on a key
const exists = await client.exists(key);
if (exists === 0) {
removeFromTree(key); // instead of toasting on every auto-refresh tick
return;
} Prevention
- Expect short-TTL keys to vanish under an open viewer; treat 0 as a normal outcome
- Stop auto-refresh loops once a key is gone (the commented-out removeInterval hint shows the intent)
- Check TTL key before opening if expiry is imminent
When it happens
Trigger: Auto/manual refresh firing after the key's TTL elapsed; key DELed from the CLI or another desktop client while its detail tab was open; key evicted with an allkeys-* policy; key renamed by another process.
Common situations: Inspecting short-lived cache keys, two tools editing the same database, debugging keys that expire mid-inspection.
Related errors
- Sentinel & Cluster cannot be checked together!
- message || this.$t('message.test_connection_failed')
- this.$t('message.test_connection_timeout')
- this.$t('message.key_type_not_support')
- Exists Error: ${e.message}
AI-assisted analysis of qishibo/AnotherRedisDesktopManager@c149855106 (2026-08-22).
Data as JSON: /api/errors/73f6c63e902ecd5b.
Report an issue: GitHub.