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
