{"record":{"id":"8d7eaf1daa59337f","repo":"qishibo/AnotherRedisDesktopManager","slug":"this-t-message-modify-failed","errorCode":null,"errorMessage":"this.$t('message.modify_failed')","messagePattern":"this\\.\\$t\\('message\\.modify_failed'\\)","errorType":"console","errorClass":null,"httpStatus":null,"severity":"error","filePath":"src/components/contents/KeyContentString.vue","lineNumber":63,"sourceCode":"      if (content === false) {\n        return;\n      }\n\n      this.client.set(\n        this.redisKey,\n        content,\n      ).then((reply) => {\n        if (reply === 'OK') {\n          // for compatibility, use expire instead of setex\n          this.setTTL();\n          this.initShow();\n\n          this.$message.success({\n            message: this.$t('message.modify_success'),\n            duration: 1000,\n          });\n        } else {\n          this.$message.error({\n            message: this.$t('message.modify_failed'),\n            duration: 1000,\n          });\n        }\n      }).catch((e) => {\n        this.$message.error(e.message);\n      });\n    },\n    setTTL() {\n      const ttl = parseInt(this.$parent.$parent.$refs.keyHeader.keyTTL);\n\n      if (ttl > 0) {\n        this.client.expire(this.redisKey, ttl).catch((e) => {\n          this.$message.error(`Expire Error: ${e.message}`);\n        }).then((reply) => {});\n      }\n    },\n    initShortcut() {","sourceCodeStart":45,"sourceCodeEnd":81,"githubUrl":"https://github.com/qishibo/AnotherRedisDesktopManager/blob/c149855106628babcdfb7675a8e7ba9434d2492a/src/components/contents/KeyContentString.vue#L45-L81","documentation":"After saving edited string content, the component treats a SET reply that is not exactly 'OK' as failure and toasts modify_failed. Standard Redis SET either replies OK or rejects the promise (handled by the adjacent .catch), so this branch is only reachable through proxies, rewritten/renamed commands, or mocks that return some other value for SET.","triggerScenarios":"A cloud proxy or protocol-translation layer in front of Redis returning a non-'OK' reply for SET; a renamed/rewritten SET command; test harnesses or fake servers that mock SET with the wrong reply.","commonSituations":"Managed Redis fronts with non-standard replies, custom server builds, integration tests mocking ioredis incorrectly.","solutions":["Reproduce in the CLI tab: SET key value, and inspect the actual reply","If a proxy is in the path, compare behavior with a direct connection to the server","In your own tooling, align mocked replies with the Redis spec (bulk 'OK')"],"exampleFix":null,"handlingStrategy":"validation","validationCode":"// validate preconditions before treating a non-OK reply as app failure\nconst type = await client.type(key);\nif (type !== 'string') {\n  throw new Error(`cannot SET: key holds ${type}`);\n}\nconst reply = await client.set(key, value);\nif (reply !== 'OK') {\n  // nonstandard backend (proxy/mock) - report the actual reply, not a generic message\n  report(`unexpected SET reply: ${reply}`);\n}","typeGuard":null,"tryCatchPattern":null,"preventionTips":["Mock SET as resolving 'OK' in tests - any other value takes the failure branch","Prefer comparing replies case-sensitively to the RESP spec ('OK')","Suspect proxies/rewrites when this branch fires but redis-cli SET returns OK"],"tags":["redis","set-command","reply-mismatch","ardm"],"backgroundTag":"redis-write-failed","analyzedSha":"c149855106628babcdfb7675a8e7ba9434d2492a","analyzedAt":"2026-08-22T09:06:28.613Z","schemaVersion":2},"datasetVersion":"2026-08-22T09:17:25.309Z"}