GPrabhudas commented on a change in pull request #560:
URL: https://github.com/apache/pulsar-client-go/pull/560#discussion_r689231734
##########
File path: pulsar/internal/commands.go
##########
@@ -221,9 +222,21 @@ func serializeBatch(wb Buffer,
cmdSend *pb.BaseCommand,
msgMetadata *pb.MessageMetadata,
uncompressedPayload Buffer,
- compressionProvider compression.Provider) {
+ compressionProvider compression.Provider,
+ encryptor crypto.Encryptor) {
// Wire format
// [TOTAL_SIZE] [CMD_SIZE][CMD] [MAGIC_NUMBER][CHECKSUM]
[METADATA_SIZE][METADATA] [PAYLOAD]
+
+ // compress the payload
+ compressedPayload := compressionProvider.Compress(nil,
uncompressedPayload.ReadableSlice())
+
+ // encrypt the compressed payload
+ encryptedPayload, err := encryptor.Encrypt(compressedPayload,
crypto.NewMessageMetadataSupplier(msgMetadata))
+ if err != nil {
+ // error occurred while encrypting the payload,
ProducerCryptoFailureAction is set to Fail
+ panic(fmt.Sprintf("Encryption of message failed,
ProducerCryptoFailureAction is set to Fail. Error :%v", err))
Review comment:
It depends on end user if they are catching the exception. Since it is
java, it is possible to catch the exception.
I think it is proper action to `panic` here because
`ProducerCryptoFailureAction=Fail` set by the user in config.
I do see other panics in the same function
[serializeBatch](https://github.com/apache/pulsar-client-go/blob/master/pulsar/internal/commands.go#L220)
and if they are recoverable then this panic can also be recovered.
--
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]
