Repository navigation
fix(kafka): deserialize empty string record key instead of returning None - #8698
ASHMEET555 wants to merge 1 commit into
Conversation
|
Thanks a lot for your first contribution! Please check out our contributing guidelines and don't hesitate to ask whatever you need. |
|
SumiRann1
left a comment
There was a problem hiding this comment.
Viewed, I think this is correct!
leandrodamascena
left a comment
There was a problem hiding this comment.
Thanks @ASHMEET555, confirmed. One thing I checked before approving: with a key schema configured, an empty key now raises KafkaConsumerDeserializationError instead of silently becoming None. That is exactly what value already does for an empty value with a schema, so the two are consistent now, and I'll call it out in the release notes.
I'm approving now. This goes out in 3.40.0, so it will sit here for a while before I merge it. No rebase needed in the meantime, and you'll be credited in the release notes.



Issue number: closes #8696
Summary
Changes
ConsumerRecordRecords.key, replace truthiness checkif not key:with identity checkif key is None:. This ensures Kafka events with empty string keys ("key": "") are deserialized properly rather than treated as absent and returningNone.KafkaEventRecord.decoded_keyinaws_lambda_powertools.utilities.data_classes.kafka_event.test_kafka_consumer_default_deserializer_key_is_empty_string.User experience
"key": ""), accessingrecord.keyreturnedNone, making it indistinguishable from a null/missing key.Nonekeys returnNone. An empty string key is preserved and deserialized (returning""by default, or passed to the configured deserializer).By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.