-
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
[Service Bus] [Core AMQP] Merge AmqpMessage{Header|Properties} exported from both the libraries #12091
[Service Bus] [Core AMQP] Merge AmqpMessage{Header|Properties} exported from both the libraries #12091
Conversation
I would recommend to take this opportunity to have a v2 for |
This pull request is protected by Check Enforcer. What is Check Enforcer?Check Enforcer helps ensure all pull requests are covered by at least one check-run (typically an Azure Pipeline). When all check-runs associated with this pull request pass then Check Enforcer itself will pass. Why am I getting this message?You are getting this message because Check Enforcer did not detect any check-runs being associated with this pull request within five minutes. This may indicate that your pull request is not covered by any pipelines and so Check Enforcer is correctly blocking the pull request being merged. What should I do now?If the check-enforcer check-run is not passing and all other check-runs associated with this PR are passing (excluding license-cla) then you could try telling Check Enforcer to evaluate your pull request again. You can do this by adding a comment to this pull request as follows: What if I am onboarding a new service?Often, new services do not have validation pipelines associated with them, in order to bootstrap pipelines for a new service, you can issue the following command as a pull request comment: |
…to harshan/sb/issue/merge-AMQP-interfaces
/azp run js - servicebus - 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.
Please pin the version of core-amqp in event hubs and service bus packages as we are using the preview version. Other than that, this looks good.
@@ -438,7 +438,7 @@ export interface ServiceBusReceivedMessage extends ServiceBusMessage { | |||
* @property {AmqpMessage} _amqpMessage The underlying raw amqp message. | |||
* @readonly | |||
*/ | |||
readonly _amqpAnnotatedMessage: AmqpAnnotatedMessage; | |||
readonly _amqpAnnotatedMessage?: AmqpAnnotatedMessage; |
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.
Making this optional will not be an accurate representation of a received message. I would recommend reverting the commit a745549 and revisiting the refactoring later.
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.
Done
…nce it is not being set in the constructor" This reverts commit a745549.
## 2.0.0-beta.1 (Unreleased) | ||
|
||
- `AmqpAnnotatedMessage` interface that closely represents the AMQP annotated message from the [AMQP spec](https://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#section-message-format) has been added. New `AmqpMessageHeaders` and `AmqpMessageProperties` interfaces(properties with camelCasing) have been added in the place of re-exports from "rhea" library(properties with snake_casing). | ||
[PR 12091](https://github.com/Azure/azure-sdk-for-js/pull/12091) |
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.
Love the changelog update. Its perfect :)
@@ -8,13 +8,13 @@ import { AbortSignalLike } from '@azure/abort-controller'; | |||
import { AccessToken } from '@azure/core-auth'; | |||
import { AmqpError } from 'rhea-promise'; | |||
import { Message as AmqpMessage } from 'rhea-promise'; |
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.
Nit: Can we keep this as Message
and not use the Amqp
prefix here? Everywhere else where we use the Amqp
prefix, we are referring to the type/interface defined in core-amqp which has camel casing. Where as this AmqpMessage
is from rhea-promise. To be consistent with MessageHeader
and MessageProperties
from rhea-promise, this should just Message
as well
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.
We either do that or use the Rhea
prefix
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 was thinking it, but refrained from doing since it would change service-bus and event-hubs.
But it is probably worth doing it.. will do!
Hello @HarshaNalluru! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
Issue #12004
Previously
Updates
Re-exporting rhea types asRemoved these re-exportsRheaAmqpMessage{Header|Properties}
instead ofAmqpMessage{Header|Properties}
from core-amqpMessage{Header|Properties}
toAmqpMessage{Header|properties}
in core-amqp (still being exported)AmqpMessage{Header|properties}
defined in service-bus and usingAmqpMessage{Header|Properties}
from core-amqp insteadAmqpMessage{Header|properties}
from core-amqp in service-bus