feat: Use base64 encoded JSON and Binary type to avoid message being …#1889
feat: Use base64 encoded JSON and Binary type to avoid message being …#1889
Conversation
…dropped by filter policies
#1889) * feat: Use base64 encoded JSON and Binary type to avoid message being dropped by filter policies * feat: Use BinaryValue, not StringValue * Feat: AWS automatically base64's the data for us, so we don't want to repeat it
#1889) * feat: Use base64 encoded JSON and Binary type to avoid message being dropped by filter policies * feat: Use BinaryValue, not StringValue * Feat: AWS automatically base64's the data for us, so we don't want to repeat it
|
This PR was originally marked as 'breaking-change' - and it definitely is, when working with a consumer in a language that is statically typed (java). The change from a String/StringValue to Binary/BinaryValue breaks any assuptions consumer languages have on consuming that header (wether they mean to or not). Specifically, the documented sqs-java-messaging-lib does not support Binary type headers at all, and throws an exception. This is obviously not a great behavior for this library in the first place, but does represent a breaking interface change here in the trace layer that I cannot escape from currently. There are a couple ways out of this in that java library, all involving forking and adding functionality. But I'm wondering, the approach in this library continues to use the |
3 participants
…dropped by filter policies
What does this PR do?
A report (DataDog/serverless-plugin-datadog#232) led us to uncover that there's an issue with passing string which contains JSON via SNS Message Attributes. Although AWS is aware of the issue, we'd rather move quickly on this and address it.
This PR moves to using a binary datatype and passing a base64 encoded string instead.
Motivation
Plugin Checklist
Additional Notes