Skip to content
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] AdminClient: ForwardTo wasn't applying on update due to bad property ordering in XML #14692

Merged
13 commits merged into from
Apr 5, 2021

Conversation

richardpark-msft
Copy link
Member

@richardpark-msft richardpark-msft commented Apr 2, 2021

The ordering of properties in the XML requests to the Service Bus ATOM API is significant and changing it can have side effects.

In this instance, the ordering issues caused us to appear to have setup forwarding properly for a queue but forwarding was NOT actually enabled. Our previous testing missed this because this data actually round-trips properly through the API but it doesn't trigger whatever actual setting needs to happen to cause forwarding to happen.

This PR reconciles our queue, topic and subscription entities ordering against the .net layer, which acts as the de-facto authority.

Fixes #14539

…ear to take effect but don't actually alter the entity.

Fixes Azure#14539
@richardpark-msft
Copy link
Member Author

/azp run js - service-bus - tests

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@ramya-rao-a
Copy link
Contributor

BTW, the analyze step is failing due to unformatted files

@richardpark-msft
Copy link
Member Author

/azp run js - service-bus - tests

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

Copy link
Contributor

@chradek chradek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, but we should file some issues for the TODO items so they don't get forgotten.

DefaultMessageTimeToLive: topic.defaultMessageTimeToLive,
MaxSizeInMegabytes: getStringOrUndefined(topic.maxSizeInMegabytes),
RequiresDuplicateDetection: getStringOrUndefined(topic.requiresDuplicateDetection),
DuplicateDetectionHistoryTimeWindow: topic.duplicateDetectionHistoryTimeWindow,
EnableBatchedOperations: getStringOrUndefined(topic.enableBatchedOperations),
// TODO: in .net, but not in here: FilteringMessagesBeforePublishing
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these TODOs meant to track adding these fields? Can we create an issue for them?

Copy link
Member

@HarshaNalluru HarshaNalluru Apr 5, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll log an issue for us for this and the one below and remove the comment.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DefaultMessageTimeToLive: topic.defaultMessageTimeToLive,
MaxSizeInMegabytes: getStringOrUndefined(topic.maxSizeInMegabytes),
RequiresDuplicateDetection: getStringOrUndefined(topic.requiresDuplicateDetection),
DuplicateDetectionHistoryTimeWindow: topic.duplicateDetectionHistoryTimeWindow,
EnableBatchedOperations: getStringOrUndefined(topic.enableBatchedOperations),
// TODO: in .net, but not in here: FilteringMessagesBeforePublishing
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// TODO: in .net, but not in here: FilteringMessagesBeforePublishing

@ghost
Copy link

ghost commented Apr 5, 2021

Hello @HarshaNalluru!

Because this pull request has the auto-merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

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 (@msftbot) and give me an instruction to get started! Learn more here.

@ghost ghost merged commit 2fe92a1 into Azure:master Apr 5, 2021
HarshaNalluru pushed a commit to HarshaNalluru/azure-sdk-for-js that referenced this pull request Apr 5, 2021
… bad property ordering in XML (Azure#14692)

The ordering of properties in the XML requests to the Service Bus ATOM API is significant and changing it can have side effects.

In this instance, the ordering issues caused us to appear to have setup forwarding properly for a queue but forwarding was NOT actually enabled. Our previous testing missed this because this data actually round-trips properly through the API but it doesn't trigger whatever actual setting needs to happen to cause forwarding to happen.

This PR reconciles our queue, topic and subscription entities ordering against the .net layer, which acts as the de-facto authority.

Fixes Azure#14539
ghost pushed a commit that referenced this pull request Apr 5, 2021
AdminClient: ForwardTo wasn't applying on update due to bad property ordering in XML (#14692)

The ordering of properties in the XML requests to the Service Bus ATOM API is significant and changing it can have side effects.

In this instance, the ordering issues caused us to appear to have setup forwarding properly for a queue but forwarding was NOT actually enabled. Our previous testing missed this because this data actually round-trips properly through the API but it doesn't trigger whatever actual setting needs to happen to cause forwarding to happen.

This PR reconciles our queue, topic and subscription entities ordering against the .net layer, which acts as the de-facto authority.

Fixes #14539
jay-most pushed a commit to jay-most/azure-sdk-for-js that referenced this pull request Apr 26, 2021
… bad property ordering in XML (Azure#14692)

The ordering of properties in the XML requests to the Service Bus ATOM API is significant and changing it can have side effects.

In this instance, the ordering issues caused us to appear to have setup forwarding properly for a queue but forwarding was NOT actually enabled. Our previous testing missed this because this data actually round-trips properly through the API but it doesn't trigger whatever actual setting needs to happen to cause forwarding to happen.

This PR reconciles our queue, topic and subscription entities ordering against the .net layer, which acts as the de-facto authority.

Fixes Azure#14539
openapi-sdkautomation bot pushed a commit to AzureSDKAutomation/azure-sdk-for-js that referenced this pull request Jul 15, 2021
Adding compute 2021-04-01 version (Azure#15100)

* initial copy of old files to new folder 2021-04-01

* api version update

* Add SpotRestorePolicy to CRP's VM Scale Set Resource (Azure#14692)

* Resolve merge conflicts after branch recreation

* Fix Lint error

* update with changes mae in 2021-03-01

* Update compute.json

* Update CreateAVmWithNetworkInterfaceConfiguration.json

update example file also to fix breaking change naming issue.

* Feature/cplat 2021 04 01 - Capacity Reservation related changes (Azure#15058)

* updated code

* updated swagger with cr changes

* updated swagger with cr changes

* updated swagger with cr changes

* updated swagger

* updated swagger

* updated swagger

* Feature/cplat 2021 04 01 (Azure#15070)

* 2021-04 initial

* 2021-04 examples and readme

* adding CR VMSS changes

* updating api version in example and description of CR profile

Co-authored-by: Adam Sandor <[email protected]>
Co-authored-by: Theodore Chang <[email protected]>

* Update compute.json

* syncronizing 2021-04-01 swagger with changes made in 2021-03-01

Co-authored-by: Sandeep Vishnu <[email protected]>
Co-authored-by: hari-bodicherla <[email protected]>
Co-authored-by: micahjo <[email protected]>
Co-authored-by: Adam Sandor <[email protected]>
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

autoDeleteOnIdle cannot be set on queue creation when also setting a dead letter forward
4 participants