Copilot commented on code in PR #13324: URL: https://github.com/apache/apisix/pull/13324#discussion_r3166994048
########## apisix/plugin.lua: ########## @@ -993,7 +993,12 @@ end -- - Arbitrary depth dotted paths (e.g., "a.b.c.d") -- - Array traversal at intermediate nodes (iterate each element) -- - Leaf type dispatch: string, array of strings, map of strings +local decrypt_hint = ". This is expected after upgrading if the field was recently " + .. "added to encrypt_fields; re-save the configuration via the Admin API to resolve" + local function process_encrypt_field(conf, key_path, operation, plugin_name, op_name) + local log_func = op_name == "decrypt" and core.log.info or core.log.warn + local hint = op_name == "decrypt" and decrypt_hint or "" Review Comment: `aes_decrypt_pkey` returns errors not only for plaintext-after-upgrade cases but also for genuine decryption problems (eg keyring/IV mismatch), and `process_encrypt_field` leaves the (still-encrypted) value in place on failure. Logging all decrypt failures at `info` and appending an unconditional “This is expected…” hint can hide/mislead operators when the value was actually expected to be decryptable. Consider keeping `warn` for at least the “decrypt ssl key failed” path or softening the hint wording (eg “This can happen after upgrading…; if the value was encrypted, verify the data_encryption keyring”). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
