Hi Yunze, Thanks for bringing this to the discussion. I'm thinking it's probably related to Pulsar support, encrypt data with different keys? might the user want to get the encryption keys from the producer?
Not pretty sure. Regards, Penghui On Thu, Dec 4, 2025 at 4:54 AM Yunze Xu <[email protected]> wrote: > Hi all, > > The encryption context was introduced from > https://github.com/apache/pulsar/pull/2024, which handles the case > when decryption failed and the original encrypted payload to the > application. > > However, even if the decryption succeeds, `Message#getEncryptionCtx` > is still not empty, this results in an issue that the application has > no way to know if the decryption failed. Hence, PIP-432 > (https://github.com/apache/pulsar/pull/24481) was proposed to add a > method `isEncrypted()` that indicates whether the message's data > (`Message#getData`) is still encrypted (i.e. the decryption failed). > > When I'm trying to implement this feature on C++ client, I realized > that this field is somehow unnecessary. If `getEncryptionCtx` returns > an empty optional when the decryption succeeds, this field will not be > needed anymore. > > The only question is if it's intentional to carry an encryption > context when the decryption succeeds. For Java clients, I understand > that it could bring breaking changes if we do so. But for other > clients, it seems that we don't need to follow this "wrong" approach. > > WDYT? > > Thanks, > Yunze >
