-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[event-hubs] add AmqpAnnotatedMessage support #15939
Conversation
/azp run js - event-hubs - tests |
Azure Pipelines successfully started running 1 pipeline(s). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some small things, nothing fatal.
There's quite a bit of code here and it looks pretty much like what Service Bus has. Is there anything notable that I should pay more attention to?
// customer on receive. | ||
if (body === undefined) body = null; | ||
if (bodyType === "value") { | ||
// TODO: Expose value_section from `rhea` similar to the data_section and sequence_section. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know this is actually my TODO but we should probably file an issue to push this change into rhea.
// string, undefined, null, boolean, array, object, number should end up here | ||
// coercing undefined to null as that will ensure that null value will be given to the | ||
// customer on receive. | ||
if (body === undefined) body = null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd throw in a blank line here - it's really easy to think the 'if' and the 'underlying else's' all are part of the same chain.
With that said - the 'body being null' thing seems incorrect to me. I know this came from SB, so it's potentially wrong there as well.
For instance, if you pass null
you get this from JSON.stringify:
> Buffer.from(JSON.stringify(null), "utf8")
<Buffer 6e 75 6c 6c>
> Buffer.from(JSON.stringify(null), "utf8").toString()
'null'
I haven't looked, but perhaps this all plays nicely with the rhea encoding method for message.<data|value|sequence>_section()
methods?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only time null
would have some transformation done on it is for the data_section
, which case it will be JSON stringified. I'd agree that this would cause a problem, except we also attempt to JSON parse any data_section bodies. This would result in the body being null
, not "null"
.
That said, we might run into a problem is when talking to the other languages. There's no guarantee other languages are also calling JSON.parse (in fact I doubt they are), so they may see 'null' as a string rather than a null type. It looks like this is already existing behavior, but since null
and 'null'
both result in null
being returned from JSON.parse, updating this is safe.
return { body: body.content, bodyType: "value" }; | ||
} | ||
} else { | ||
// TODO: test case |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a TODO because it's not done yet or is there an interesting challenge here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Haha, I meant to erase that but the problem with adding TODOs is you have to actually go back and grep them...
}; | ||
} else { | ||
let bodyType: BodyTypes = "data"; | ||
if (typeof (data as EventDataInternal).getRawAmqpMessage === "function") { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this check is basically isReceivedEventData(), more or less?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now, yes, exactly.
properties: data.properties, | ||
offset: data.offset!, | ||
sequenceNumber: data.sequenceNumber!, | ||
enqueuedTimeUtc: data.enqueuedTimeUtc!, | ||
partitionKey: data.partitionKey!, | ||
systemProperties: data.systemProperties | ||
systemProperties: data.systemProperties, | ||
getRawAmqpMessage() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I take the lack of an underscore here is a personal rebuke.
The only notable difference is that in Event Hubs, I'm using |
/azp run js - event-hubs - tests |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run js - event-hubs - tests |
Azure Pipelines successfully started running 1 pipeline(s). |
[Hub Generated] Review request for Microsoft.LabServices to add version preview/2021-10-01-preview (Azure#15939) * Adds base for updating Microsoft.LabServices from version stable/2018-10-15 to version 2021-10-01-preview * Updates readme * Updates API version in new specs and examples * remove 2018 api spec files * add 2021-10-01-preview spec files from generation * update preview api files in readme.md input * update 2020 -> 2021 in new api version in readme * spelling fixes * fix object body mutability * add type:object where missing * added default error response * tracker resource operation naming and description adding * fix shutdownOnIdleEnabled in examples * fix shutdownonIdle enum in examples * examples update username to adminUser object and remove locations from vmprofile * fix examples for vmprofile * rest of model validaiton fixes * prettier fix * removed skus api from 2021-10-01 version since it's not finished * fix operationresults * small images fix Co-authored-by: Nick Depinet <ndepinet@microsoft.com>
Resolves #15769
Goal
Increase interopability with other AMQP-based services (e.g. Service Bus).
Background
EventData
currently exposes the curated set of information available from messages using the AMQP protocol. There isn't currently a way for users to send or receive a raw AMQP message. The Service Bus client library was updated to add support for reading theAmqpAnnotatedMessage
from a received message, and sending anAmqpAnnotatedMessage
via adding it to a batch, or sending it directly to the service.Changes
ReceivedEventData
with agetRawAmqpMessage()
method that returnsAmqpAnnotatedMessage
.EventData
:contentType
: stringmessageId
: stringcorrelationId
: stringDifferences from Service Bus
ServiceBus has a readonly
_rawAmqpMessage
property onServiceBusReceivedMessage
instead of thegetRawAmqpMessage()
method. Since this is a public API, we should not have prefixed the field with an underscore. Changing this to a method has us similar to what other languages are doing, and gives us flexibility to pass options in the future (for example, if we decide we want to parse timestamps as dates instead of numbers, we can control that in an option in the future)If this API is accepted, I will deprecate
_rawAmqpMessage
and add the same method in Service Bus.References:
Azure/azure-sdk-for-net#20105