-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[ServiceBus] Fix an issue where user error handler is not called (#19189
) when subscribing to a valid topic but an invalid or disabled subscription. Issue #18798 The problem is that in these cases, the service accepts our client's cbs claim negotiation, and the receiver link is created. The [client receiver enters](https://github.com/Azure/azure-sdk-for-js/blob/14099039a8009d6d9687daf65d22a998e3ad7920/sdk/servicebus/service-bus/src/core/streamingReceiver.ts#L539) the `retryForeverFn` to call `_initAndAddCreditOperation()`, where the following ```ts await this._messageHandlers().postInitialize(); this._receiverHelper.addCredit(this.maxConcurrentCalls); ``` will return successfully, despite that the fired-and-forgot `addCredit()` call would later leads to `MessagingEntityDisabled` or `MessagingEntityNotFound` errors in the underlying link. Since there's no errors thrown in our retry-forever loop, the `onErrors()` [callback](https://github.com/Azure/azure-sdk-for-js/blob/14099039a8009d6d9687daf65d22a998e3ad7920/sdk/servicebus/service-bus/src/core/streamingReceiver.ts#L541) is not invoked. It is one place where the user error handler is called. Because of the error, the link is detatched. We have code to re-establish the link when errors happen, so we call `_subscribeImpl()` where the `retryForeverFn()` is called again. This goes on in an endless loop. We used to invoke user error handler and would not attempt to re-establish connections when errors are considered non-retryable. In PR #11973 we removed the classification of errors that `subscribe()` used and instead continues to retry infinitely. We also removed the code to invoke user error handler. This PR adds code to invoke the user error handler in `_onAmqpError()` so users have a chance to stop the infinite loop. There's another problem. When users call `close()` on the subscription in their error handler, `this._receiverHelper.suspend()` is called to suspend the receiver. However, when re-connecting we call `this._receiverHelper.resume()` again in `_subscribeImpl()`. This essentially reset the receiver to be active and we will not abort the attempt to initialize connection https://github.com/Azure/azure-sdk-for-js/blob/14099039a8009d6d9687daf65d22a998e3ad7920/sdk/servicebus/service-bus/src/core/streamingReceiver.ts#L574-L579 To fix it, this PR moves the `resume()` call out. It is supposed to only called to enable receiver before subscribing. It should not be called when we try to re-connect. * Update ref doc on the receiver subscribe error handler * Apply suggestions from code review Co-authored-by: Ramya Rao <[email protected]> * Bring back processError() call in _onSessionError() callback * Clarify that we retry on all errors when streaming and link to ref doc on service bus errors. * Bring back comments for resume() call Also fix linting issue. The linter insists "@" in ts-doc should be escaped. The url still works after adding "\" * Re-remove comments Co-authored-by: Ramya Rao <[email protected]>
- Loading branch information
1 parent
6b7e478
commit 2b2b9a4
Showing
4 changed files
with
113 additions
and
14 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters