profile
viewpoint
Ramya Rao ramya-rao-a Microsoft Redmond, WA Software Engineering Manager at @microsoft leading the team that builds JS libraries for Azure services.

microsoft/vscode-go 5981

An extension for VS Code which provides support for the Go language. We have moved to https://github.com/golang/vscode-go

Azure/azure-event-hubs-node 53

Node client library for Azure Event Hubs https://azure.microsoft.com/services/event-hubs

Azure/ms-rest-js 42

Runtime for isomorphic javascript libraries generated by Autorest

microsoft/vscode-emmet 29

Emmet features via extension for Visual Studio Code using the new API

microsoft/vscode-emmet-helper 21

A helper module to use emmet modules with Visual Studio Code

amqp/rhea-promise 12

A promisified layer over rhea AMQP client

Azure/autorest.nodejs 6

Extension for AutoRest (https://github.com/Azure/autorest) that generates JavaScript code

Azure/amqp-common-js 2

Azure AMQP abstractions for javascript/typescript that contains common types and interfaces for use in Service Bus and Event Hubs.

ramya-rao-a/azure-sdk-for-js 1

An isomorphic javascript sdk for Azure services

Pull request review commentAzure/azure-sdk-for-js

[service-bus] Make subscribe() more resilient against errors.

 export class StreamingReceiver extends MessageReceiver {       // These should be ignored until the already running `onDetached` completes       // its retry attempts or errors.       logger.verbose(-        `${this.logPrefix} Call to detached on streaming receiver '${this.name}' is already in progress.`+        `${this.logPrefix} onDetached: Call to detached on streaming receiver '${this.name}' is already in progress.`       );       return;     }      this._isDetaching = true; +    const translatedError = receiverError ? translate(receiverError) : receiverError;+    logger.logError(+      translatedError,+      `${this.logPrefix} onDetached: Reinitializing receiver because of error`+    );+     try {       // Clears the token renewal timer. Closes the link and its session if they are open.       // Removes the link and its session if they are present in rhea's cache.       await this.closeLink();+    } catch (err) {+      logger.verbose(+        `${this.logPrefix} onDetached: Encountered an error when closing the previous link: `,+        err+      );+    } -      const translatedError = receiverError ? translate(receiverError) : receiverError;--      // Track-1-      //   - We should only attempt to reopen if either no error was present,-      //     or the error is considered retryable.-      // Track-2-      //  Reopen-      //   - If no error was present-      //   - If the error is a MessagingError and is considered retryable-      //   - Any non MessagingError because such errors do not get-      //     translated by `@azure/core-amqp` to a MessagingError-      //   - More details here - https://github.com/Azure/azure-sdk-for-js/pull/8580#discussion_r417087030-      const shouldReopen =-        translatedError instanceof MessagingError ? translatedError.retryable : true;--      // Non-retryable errors that aren't caused by disconnect-      // will have already been forwarded to the user's error handler.-      // Swallow the error and return quickly.-      if (!shouldReopen && !causedByDisconnect) {-        logger.logError(-          translatedError,-          "%s Encountered a non retryable error on the receiver. Cannot recover receiver. encountered error",-          this.logPrefix,-          this.name,-          this.address-        );-        return;-      }--      // Non-retryable errors that are caused by disconnect-      // haven't had a chance to show up in the user's error handler.-      // Rethrow the error so the surrounding try/catch forwards it appropriately.-      if (!shouldReopen && causedByDisconnect) {-        logger.logError(-          translatedError,-          "%s Encountered a non retryable error on the connection. Cannot recover receiver.",-          this.logPrefix,-          this.name,-          this.address-        );-        throw translatedError;-      }+    try {+      await this.init({+        // provide a new name to the link while re-connecting it. This ensures that+        // the service does not send an error stating that the link is still open.+        useNewName: true,+        connectionId: this._context.connectionId,+        onError: (args) => this._onError && this._onError(args)+      }); -      // shall retry forever at an interval of 15 seconds if the error is a retryable error-      // else bail out when the error is not retryable or the operation succeeds.-      const config: RetryConfig<void> = {-        operation: () =>-          this.init(-            // provide a new name to the link while re-connecting it. This ensures that-            // the service does not send an error stating that the link is still open.-            true-          ).then(() => {-            this._receiverHelper.addCredit(this.maxConcurrentCalls);-            return;-          }),-        connectionId: connectionId,-        operationType: RetryOperationType.receiverLink,-        retryOptions: this._retryOptions,-        connectionHost: this._context.config.host-      };-      // Attempt to reconnect. If a non-retryable error is encountered,-      // retry will throw and the error will surface to the user's error handler.-      await retry<void>(config);+      this._receiverHelper.addCredit(this.maxConcurrentCalls);+      logger.verbose(+        `${this.logPrefix} onDetached: link has been reestablished, added ${this.maxConcurrentCalls} credits.`+      );     } catch (err) {+      // the behavior of init() is such that it should _never_ throw an error. If it does then the library is doing+      // something completely incorrect and we need to report it because it's unlikely that we'll properly+      // recover from it.       logger.logError(         err,-        "%s An error occurred while processing detached()",-        this.logPrefix,-        this.name,-        this.address+        `${this.logPrefix} onDetached: A fatal internal error has occurred. Connection will not be reestablished`       );-      if (typeof this._onError === "function") {-        logger.verbose(`${this.logPrefix} Unable to automatically reconnect`);-        try {-          this._onError({-            error: err,-            errorSource: "receive",-            entityPath: this.entityPath,-            fullyQualifiedNamespace: this._context.config.host-          });-        } catch (err) {-          logger.logError(-            err,-            `${this.logPrefix} User-code error in error handler called after disconnect`-          );-        } finally {-          // Once the user's error handler has been called,-          // close the receiver to prevent future messages/errors from being received.-          // Swallow errors from the close rather than forwarding to user's error handler-          // to prevent a never ending loop.-          await this.close().catch(() => {});-        }-      }++      this._onError &&+        this._onError({+          errorSource: "internal",

I realized that we will hit this code path when the user makes use of the abort signal. In which case the error source is not really internal...

Instead of throwing the AbortError from inside init(), should the error be simply reported to the user's error handler and then we do nothing else?

richardpark-msft

comment created time in 8 hours

PullRequestReviewEvent

Pull request review commentAzure/azure-sdk-for-js

[service-bus] Make subscribe() more resilient against errors.

 export class StreamingReceiver extends MessageReceiver {     await this._receiverHelper.suspend();   } -  async init(useNewName: boolean, abortSignal?: AbortSignalLike): Promise<void> {-    const options = this._createReceiverOptions(useNewName, this._getHandlers());-    await this._init(options, abortSignal);+  /**+   * Returns a wrapped function that makes any thrown errors retryable by wrapping them+   * in a StreamingReceiverError  _except_  for AbortError.

Nit:

   * Returns a wrapped function that makes any thrown errors _except_  for AbortError
   * retryable by wrapping them in a StreamingReceiverError  .
richardpark-msft

comment created time in 8 hours

PullRequestReviewEvent

Pull request review commentAzure/azure-sdk-for-js

[service-bus] Make subscribe() more resilient against errors.

 export class StreamingReceiver extends MessageReceiver {     };      this._onAmqpError = (context: EventContext) => {-      const receiver = this.link || context.receiver!;       const receiverError = context.receiver && context.receiver.error;       if (receiverError) {         const sbError = translate(receiverError) as MessagingError;         logger.logError(sbError, `${this.logPrefix} An error occurred for Receiver`);

For a future PR, we can consider removing the handler for receiver_error and session_error event altogether because we believe that these events are always followed by the receiver_close and session_close events being called where we log the error anyway

richardpark-msft

comment created time in 8 hours

PullRequestReviewEvent

Pull request review commentAzure/azure-sdk-for-js

[service-bus] Make subscribe() more resilient against errors.

 export class StreamingReceiver extends MessageReceiver {     };      this._onAmqpError = (context: EventContext) => {-      const receiver = this.link || context.receiver!;       const receiverError = context.receiver && context.receiver.error;       if (receiverError) {         const sbError = translate(receiverError) as MessagingError;         logger.logError(sbError, `${this.logPrefix} An error occurred for Receiver`);

Same for the session case

richardpark-msft

comment created time in 8 hours

PullRequestReviewEvent

Pull request review commentAzure/azure-sdk-for-js

[service-bus] Make subscribe() more resilient against errors.

 export class StreamingReceiver extends MessageReceiver {     };      this._onAmqpError = (context: EventContext) => {-      const receiver = this.link || context.receiver!;       const receiverError = context.receiver && context.receiver.error;       if (receiverError) {         const sbError = translate(receiverError) as MessagingError;         logger.logError(sbError, `${this.logPrefix} An error occurred for Receiver`);

I would recommend the format we use in the link close event here as well

        logger.logError(sbError, `${this.logPrefix} 'receiver_error' event occurred. The associated error is`);
richardpark-msft

comment created time in 8 hours

PullRequestReviewEvent

Pull request review commentAzure/azure-sdk-for-js

[service-bus] Make subscribe() more resilient against errors.

 export interface ProcessErrorArgs {    * 'processMessageCallback': Errors thrown from the user's `processMessage` callback passed to `subscribe`.    * 'receive': Errors thrown when receiving messages.    * 'renewLock': Errors thrown when automatic lock renewal fails.-   */-  errorSource: "abandon" | "complete" | "processMessageCallback" | "receive" | "renewLock";+   * 'internal': Errors thrown when the library fails internally.

What do you think of adding a This should not happen. If it does, please log an issue at .... with the error details?

richardpark-msft

comment created time in 8 hours

PullRequestReviewEvent

issue commentAzure/azure-sdk-for-python

[Azure Event Hub]- Sending Event Message with Partition Key of type int is DANGEROUS

Thanks for reviving this topic @samuelkoppes

Addressing @jsquire's options below

Do we investigate whether there is a way to be looser with type checking and coerce non-string values to string in the non-Python libraries?

On the receiving side, we can either coerce non string values to string, or ignore the non string values altogether. I would prefer the ignoring approach to be in sync with what the service does and not mislead the user to think that their non string partition key was actually used by the service. We can also check if the service would consider doing this instead of the client i.e. remove the partition key from the message annotation since it is invalid.

Do we introduce a breaking change to the Python library to validate the type matches the documentation?

No, breaking change is not an option.

Do we leave the Python behavior as-is and consider a stronger warning in documentation about cross-language compatibility?

Yes, we should.

Do we introduce breaking changes to the other libraries to allow a generic object value and, if so, does that include the track one libraries as well?

No, breaking change is not an option.

aliyevmirzakhan

comment created time in 8 hours

pull request commentAzure/azure-sdk-for-python

[ServiceBus] Add distributed tracing to sending and receiving flows.

cc @richardpark-msft for awareness and to see if this is in sync with what we are doing in JS land

KieranBrantnerMagee

comment created time in 9 hours

Pull request review commentAzure/azure-sdk-for-python

Service Bus Connection String Parser

+# --------------------------------------------------------------------------------------------+# Copyright (c) Microsoft Corporation. All rights reserved.+# Licensed under the MIT License. See License.txt in the project root for license information.+# --------------------------------------------------------------------------------------------+try:+    from urllib.parse import urlparse+except ImportError:+    from urlparse import urlparse  # type: ignore++from azure.servicebus.management._models import DictMixin++class ServiceBusConnectionStringProperties(DictMixin):+    """+    Properties of a connection string.+    """+    def __init__(self, **kwargs):+        self.fully_qualified_namespace = kwargs.pop('fully_qualified_namespace', None)+        self.endpoint = kwargs.pop('endpoint', None)+        self.entity_path = kwargs.pop('entity_path', None)+        self.shared_access_signature = kwargs.pop('shared_access_signature', None)+        self.shared_access_key_name = kwargs.pop('shared_access_key_name', None)+        self.shared_access_key = kwargs.pop('shared_access_key', None)+++class ServiceBusConnectionStringParser(object):+    """Parse the connection string.++    :param conn_str: The connection string that has to be parsed.+    """+    def __init__(self, conn_str):+        # type: (str) -> None+        """+        :param conn_str: The connection string to parse.+        :type conn_str: str+        """+        self._conn_str = conn_str++    def parse(self):+        # type() -> ServiceBusConnectionStringProperties+        """+        Parse the connection string.+        """+        conn_str = self._conn_str.rstrip(";")+        conn_settings = [s.split("=", 1) for s in conn_str.split(";")]+        if any(len(tup) != 2 for tup in conn_settings):+            raise ValueError("Connection string is either blank or malformed.")+        conn_settings = dict(conn_settings)+        shared_access_signature = conn_settings.get('SharedAccessSignature')+        shared_access_key = conn_settings.get('SharedAccessKey')

All the keys other than SharedAccessSignature have a format and casing that is well defined. My recommendation would be to stick to that. I believe the other languages are being case sensitive

rakshith91

comment created time in 9 hours

PullRequestReviewEvent

Pull request review commentAzure/azure-sdk-for-python

Service Bus Connection String Parser

+# --------------------------------------------------------------------------------------------+# Copyright (c) Microsoft Corporation. All rights reserved.+# Licensed under the MIT License. See License.txt in the project root for license information.+# --------------------------------------------------------------------------------------------+try:+    from urllib.parse import urlparse+except ImportError:+    from urlparse import urlparse  # type: ignore++from azure.servicebus.management._models import DictMixin++class ServiceBusConnectionStringProperties(DictMixin):+    """+    Properties of a connection string.+    """+    def __init__(self, **kwargs):+        self.fully_qualified_namespace = kwargs.pop('fully_qualified_namespace', None)+        self.endpoint = kwargs.pop('endpoint', None)+        self.entity_path = kwargs.pop('entity_path', None)+        self.shared_access_signature = kwargs.pop('shared_access_signature', None)+        self.shared_access_key_name = kwargs.pop('shared_access_key_name', None)+        self.shared_access_key = kwargs.pop('shared_access_key', None)+++class ServiceBusConnectionStringParser(object):+    """Parse the connection string.++    :param conn_str: The connection string that has to be parsed.+    """+    def __init__(self, conn_str):+        # type: (str) -> None+        """+        :param conn_str: The connection string to parse.+        :type conn_str: str+        """+        self._conn_str = conn_str++    def parse(self):+        # type() -> ServiceBusConnectionStringProperties+        """+        Parse the connection string.+        """+        conn_str = self._conn_str.rstrip(";")+        conn_settings = [s.split("=", 1) for s in conn_str.split(";")]+        if any(len(tup) != 2 for tup in conn_settings):+            raise ValueError("Connection string is either blank or malformed.")+        conn_settings = dict(conn_settings)+        shared_access_signature = conn_settings.get('SharedAccessSignature')+        shared_access_key = conn_settings.get('SharedAccessKey')+        if shared_access_signature is not None and shared_access_key is not None:+            raise ValueError("Only one of the SharedAccessKey or SharedAccessSignature must be present.")

Yes, the issue that Jesse logged does talk about validation. See #14574

In JS, my initial approach was to not have any validation and simply return a dictionary of all the key/value pairs in the connection string. You can see the discussion for this in https://github.com/Azure/azure-sdk-for-js/pull/11909

But, what we landed on was a helper method that takes the connection string, performs validation and returns a strongly typed output. See https://github.com/Azure/azure-sdk-for-js/pull/11909

In terms of validation, you can see what we did in JS here: https://github.com/Azure/azure-sdk-for-js/blob/112bb1da8c66ba90655413e3a76c0a899f2d1dee/sdk/servicebus/service-bus/src/util/connectionStringUtils.ts#L63-L81

rakshith91

comment created time in 9 hours

PullRequestReviewEvent

Pull request review commentAzure/azure-sdk-for-js

[Service Bus] ATOM API - Update `update` methods with better param names/types and rephrased docs 👓

 export class ServiceBusAdministrationClient extends ServiceClient {     ruleExists(topicName: string, subscriptionName: string, ruleName: string, operationOptions?: OperationOptions): Promise<boolean>;     subscriptionExists(topicName: string, subscriptionName: string, operationOptions?: OperationOptions): Promise<boolean>;     topicExists(topicName: string, operationOptions?: OperationOptions): Promise<boolean>;-    updateQueue(queue: QueueProperties, operationOptions?: OperationOptions): Promise<WithResponse<QueueProperties>>;-    updateRule(topicName: string, subscriptionName: string, rule: RuleProperties, operationOptions?: OperationOptions): Promise<WithResponse<RuleProperties>>;-    updateSubscription(subscription: SubscriptionProperties, operationOptions?: OperationOptions): Promise<WithResponse<SubscriptionProperties>>;-    updateTopic(topic: TopicProperties, operationOptions?: OperationOptions): Promise<WithResponse<TopicProperties>>;+    updateQueue(queuePropertiesWithResponse: WithResponse<QueueProperties>, operationOptions?: OperationOptions): Promise<WithResponse<QueueProperties>>;

I dont see the API view updated though...

HarshaNalluru

comment created time in 13 hours

PullRequestReviewEvent

Pull request review commentAzure/azure-sdk-for-js

[service-bus] Make subscribe() more resilient against errors.

 export class StreamingReceiver extends MessageReceiver {     await this._receiverHelper.suspend();   } -  async init(useNewName: boolean, abortSignal?: AbortSignalLike): Promise<void> {-    const options = this._createReceiverOptions(useNewName, this._getHandlers());-    await this._init(options, abortSignal);+  private static wrapRetryOperation(+    entityPath: string,+    fullyQualifiedNamespace: string,+    fn: () => Promise<void>,+    onError?: OnError+  ) {+    return async () => {+      try {+        await fn();+      } catch (err) {+        onError &&+          onError({+            error: err,+            errorSource: "receive",+            entityPath,+            fullyQualifiedNamespace+          });++        if (err.name !== "AbortError") {+          err.retryable = true;

Ok, but then we should be treating non retryable errors as retryable. The outer while loop will take care of the retries anyway

richardpark-msft

comment created time in 14 hours

PullRequestReviewEvent

Pull request review commentAzure/azure-sdk-for-js

[service-bus] Make subscribe() more resilient against errors.

 export class StreamingReceiver extends MessageReceiver {        const translatedError = receiverError ? translate(receiverError) : receiverError; -      // Track-1-      //   - We should only attempt to reopen if either no error was present,-      //     or the error is considered retryable.-      // Track-2-      //  Reopen-      //   - If no error was present-      //   - If the error is a MessagingError and is considered retryable-      //   - Any non MessagingError because such errors do not get-      //     translated by `@azure/core-amqp` to a MessagingError-      //   - More details here - https://github.com/Azure/azure-sdk-for-js/pull/8580#discussion_r417087030-      const shouldReopen =-        translatedError instanceof MessagingError ? translatedError.retryable : true;--      // Non-retryable errors that aren't caused by disconnect-      // will have already been forwarded to the user's error handler.-      // Swallow the error and return quickly.-      if (!shouldReopen && !causedByDisconnect) {-        logger.logError(-          translatedError,-          "%s Encountered a non retryable error on the receiver. Cannot recover receiver. encountered error",-          this.logPrefix,-          this.name,-          this.address-        );-        return;-      }+      logger.logError(+        translatedError,+        `${this.logPrefix} Encountered an error on the connection. Reinitializing receiver.`+      ); -      // Non-retryable errors that are caused by disconnect-      // haven't had a chance to show up in the user's error handler.-      // Rethrow the error so the surrounding try/catch forwards it appropriately.-      if (!shouldReopen && causedByDisconnect) {-        logger.logError(-          translatedError,-          "%s Encountered a non retryable error on the connection. Cannot recover receiver.",-          this.logPrefix,-          this.name,-          this.address-        );-        throw translatedError;+      if (translatedError && this._onError) {+        this._onError({

That sounds good, but then you will need to remove the call to the user's error handler from the AMQP link & session error event handler

richardpark-msft

comment created time in 14 hours

PullRequestReviewEvent

Pull request review commentAzure/azure-sdk-for-js

[service-bus] Make subscribe() more resilient against errors.

 export class ServiceBusReceiverImpl implements ServiceBusReceiver {       });   } -  private _createStreamingReceiver(-    context: ConnectionContext,-    entityPath: string,-    options: CreateStreamingReceiverOptions+  private async _createStreamingReceiver(+    options: StreamingReceiverInitArgs   ): Promise<StreamingReceiver> {-    return StreamingReceiver.create(context, entityPath, options);+    throwErrorIfConnectionClosed(this._context);+    if (options.autoComplete == null) options.autoComplete = true;++    this._streamingReceiver =+      this._streamingReceiver ?? new StreamingReceiver(this._context, this.entityPath, options);

@HarshaNalluru, yes this is for when we want to re-use the existing receiver link for another subscribe() call @richardpark-msft This is fine

richardpark-msft

comment created time in 14 hours

PullRequestReviewEvent

issue closedAzure/azure-sdk-for-java

[FEATURE REQ] receiveMessages() call in async client should continue to try to receive messages unless stopped by the user

Today, in the latest preview of v7 of the Service Bus package, the receiveMessages() call on the async receiver is responsible to continuously receive messages. It stops receiving when

  • encountering a non retryable error on the AMQP receiver link
  • encounters a retryable error and exhausts the retry attempts as defined in the retry policy set on the client.

Since the usage of this call is to receive a continuous set of messages, this should not ideally stop until explicitly stopped by the user. At the same time, there should be a set of errors that we consider as fatal which should should stop the call.

closed time in 14 hours

ramya-rao-a

issue commentAzure/azure-sdk-for-java

[FEATURE REQ] receiveMessages() call in async client should continue to try to receive messages unless stopped by the user

Closing in favor of #16087

cc @conniey, @hemanttanwar, @srnagar

ramya-rao-a

comment created time in 14 hours

issue commentAzure/azure-sdk-for-java

[FEATURE REQ] Callback model to receive messages for non reactor users

We are going with a dedicated processor client for this purpose which will have its own builders. For feature parity with the older package, this processor client will

  • take callbacks to process messages and process errors
  • run essentially forever until user stops it. When retry attempts are exhausted on an retryable error or if a non retryable error is encountered, the user's error callback is called
  • the session variant will work across multiple sessions concurrently based on the maxConcurrentSession passed to the session variant of the builder
  • support the auto complete feature and auto lock renewal feature
public final class ServiceBusProcessorClient {
    // non-public constructors
    ServiceBusProcessorClient(Consumer<ServiceBusProcessorContext> processMessage, Consumer<Throwable> processError, MessageProcessorOptions options) {}
    
    public void start() {}

    public void stop() {}
    
    public void close() {}
    
    public boolean isRunning() {}
}
ramya-rao-a

comment created time in 14 hours

Pull request review commentAzure/azure-sdk-for-js

[service-bus] Make subscribe() more resilient against errors.

 export class StreamingReceiver extends MessageReceiver {     await this._receiverHelper.suspend();   } -  async init(useNewName: boolean, abortSignal?: AbortSignalLike): Promise<void> {-    const options = this._createReceiverOptions(useNewName, this._getHandlers());-    await this._init(options, abortSignal);+  private static wrapRetryOperation(+    entityPath: string,+    fullyQualifiedNamespace: string,+    fn: () => Promise<void>,+    onError?: OnError+  ) {+    return async () => {+      try {+        await fn();+      } catch (err) {+        onError &&+          onError({

On second thoughts, I dont see the need for wrapRetryOperation either...

richardpark-msft

comment created time in 17 hours

PullRequestReviewEvent

Pull request review commentAzure/azure-sdk-for-js

[service-bus] Make subscribe() more resilient against errors.

 export class StreamingReceiver extends MessageReceiver {     await this._receiverHelper.suspend();   } -  async init(useNewName: boolean, abortSignal?: AbortSignalLike): Promise<void> {-    const options = this._createReceiverOptions(useNewName, this._getHandlers());-    await this._init(options, abortSignal);+  private static wrapRetryOperation(+    entityPath: string,+    fullyQualifiedNamespace: string,+    fn: () => Promise<void>,+    onError?: OnError+  ) {+    return async () => {+      try {+        await fn();+      } catch (err) {+        onError &&+          onError({

Now that we are reporting the error to the user's callback inside the while loop, we shouldnt need to do the same here right?

richardpark-msft

comment created time in 17 hours

PullRequestReviewEvent

Pull request review commentAzure/azure-sdk-for-js

[service-bus] Make subscribe() more resilient against errors.

 export class StreamingReceiver extends MessageReceiver {     await this._receiverHelper.suspend();   } -  async init(useNewName: boolean, abortSignal?: AbortSignalLike): Promise<void> {-    const options = this._createReceiverOptions(useNewName, this._getHandlers());-    await this._init(options, abortSignal);+  private static wrapRetryOperation(+    entityPath: string,+    fullyQualifiedNamespace: string,+    fn: () => Promise<void>,+    onError?: OnError+  ) {+    return async () => {+      try {+        await fn();+      } catch (err) {+        onError &&+          onError({+            error: err,+            errorSource: "receive",+            entityPath,+            fullyQualifiedNamespace+          });++        if (err.name !== "AbortError") {+          throw new StreamingReceiverError(err);+        }++        // once we're at this point where we can spin up a connection we're past the point+        // of fatal errors like the connection string just outright being malformed, for instance.+        throw err;+      }+    };+  }++  /**+   * Initializes the link. This method will retry infinitely until a connection is established.+   *+   * The retries are broken up into cycles. For each cycle we do a set of retries, using the user's+   * configured retryOptions. If that retry call fails we will report the error and then go into a+   * new cycle, repeating the retries the same as before.+   *+   * It is completely up to the user to break out of this retry cycle by either:
   * It is completely up to the user to break out of this retry cycle in their error handler by either:
richardpark-msft

comment created time in 17 hours

PullRequestReviewEvent

issue closedAzure/azure-sdk

Update docfx.yml for identical markdown naming across monikers

@ramya-rao-a brought up an extremely good point that the transition between monikers is pretty much impossible from the overview selection.

Right now, docs-ref-services/<target>.md is referred to by all 3 of the monikers. This is configured in the docfx.yml. This means that a readme for preview HAS to have a different name than a readme for latest.

We should instead duplicate the docs-ref-services (or add subfolders) that can be named the same. Then, in the docfx.yml, we copy the source folder for the moniker only to the target platform. This will allow each moniker to refer to the "same path", but have different published content.

I'm about 50/50 on whether the docs publishing will consume handle the above appropriately. Will need to prototype before we do this full scale.

closed time in 18 hours

scbedd

issue commentAzure/azure-sdk

Update docfx.yml for identical markdown naming across monikers

Closing in favor of #1825

scbedd

comment created time in 18 hours

Pull request review commentAzure/azure-sdk-for-js

[service-bus] Make subscribe() more resilient against errors.

 const systemErrorFieldsToCopy: (keyof Omit<NetworkSystemError, "name" | "message   "syscall" ]; +/**+ * AMQP messaging error codes+ */+export type MessageErrorCodes =

Agreed, please log an issue for the backlog

richardpark-msft

comment created time in 19 hours

PullRequestReviewEvent

issue commentAzure/azure-sdk-for-java

Bug: Add validation scheduleMessage(Iterator<SBM>) : If all the messages can not be added into batch

Do we have this validation in Event Hubs already?

hemanttanwar

comment created time in 20 hours

Pull request review commentAzure/azure-sdk-for-js

[service-bus] Make subscribe() more resilient against errors.

 export enum EntityNames { export function isMessagingError(err: any): err is MessagingError {

What a catch!

richardpark-msft

comment created time in 20 hours

PullRequestReviewEvent

Pull request review commentAzure/azure-sdk-for-js

[service-bus] Make subscribe() more resilient against errors.

 export class StreamingReceiver extends MessageReceiver {     await this._receiverHelper.suspend();   } -  async init(useNewName: boolean, abortSignal?: AbortSignalLike): Promise<void> {-    const options = this._createReceiverOptions(useNewName, this._getHandlers());-    await this._init(options, abortSignal);+  private static wrapRetryOperation(+    entityPath: string,+    fullyQualifiedNamespace: string,+    fn: () => Promise<void>,+    onError?: OnError+  ) {+    return async () => {+      try {+        await fn();+      } catch (err) {+        onError &&+          onError({+            error: err,+            errorSource: "receive",+            entityPath,+            fullyQualifiedNamespace+          });++        if (err.name !== "AbortError") {+          err.retryable = true;

This is the part which gets me thinking if we should even re-use the retry() method. We already have a while loop in place. Why not place a sleep between each iteration of the while loop as long as there is an error and be done with it?

richardpark-msft

comment created time in 20 hours

PullRequestReviewEvent

issue closedAzure/azure-sdk-for-js

[Service Bus] Remove viaPartitionKey to be added when we have Transactions support

The ServiceBusMessage in the Service Bus package has the viaPartitionKey property which is related to the Transactions feature in Service Bus that we dont support yet. This issue is to remove this property for now to allow any re-design/re-name on this front in the future

PRs are welcome to add this feature. Code Pointers:

  • Set up environment and run rush build
  • Open the sdk/servicebus/service-bus folder in your editor/IDE, find the ServiceBusMessage interface and get started

closed time in 20 hours

ramya-rao-a

issue commentAzure/azure-sdk-for-js

[Service Bus] Remove viaPartitionKey to be added when we have Transactions support

This is done with #12026

Thanks @mohsin-mehmood!

ramya-rao-a

comment created time in 20 hours

push eventAzure/azure-sdk-for-js

Mohsin Mehmood

commit sha aba7d47f9c45f2239e74e48d82d1d4cbe60c0099

Servicebus remove viapartitionkey until Transactions are supported (#12026)

view details

push time in 20 hours

PR merged Azure/azure-sdk-for-js

Reviewers
Servicebus remove viapartitionkey Service Bus customer-reported

PR for #11955

+45 -31

5 comments

6 changed files

mohsin-mehmood

pr closed time in 20 hours

PullRequestReviewEvent

issue commentAzure/azure-sdk-for-js

Azure Service Bus Samples Issues

Thanks for reporting @JosueJoshua

Your recommendation is right. label needs to be updated to subject

JosueJoshua

comment created time in a day

issue commentAzure/azure-sdk-for-js

Azure Metrics advisor Readme Issues

Thanks for reporting @JosueJoshua

@KarishmaGhiya Should the link text be updated here or the example header?

JosueJoshua

comment created time in a day

issue commentAzure/azure-sdk-for-js

[Service Bus] Browser requests do not work unless web security is disabled

Ok, lets document this in the readme for now and then work with the service team in the coming months to see how best to fix this

ramya0820

comment created time in a day

pull request commentAzure/azure-sdk-for-js

Acataldi/10779 fix schema registry lint errors

Thanks @abc516!

abc516

comment created time in a day

Pull request review commentAzure/azure-sdk-for-js

Acataldi/10779 fix schema registry lint errors

 const testGroup = "azsdk_js_test_group"; const testSchemaIds = [   "{773E17BE-793E-40B0-98F1-0A6EA3C11895}",   "{DC7EF290-CDB1-4245-8EE8-3DD52965866E}"-].map((x) => x.replace(/[\{\-\}]/g, ""));+].map((x) => x.replace(/[{\-}]/g, ""));

Thanks Nick

abc516

comment created time in a day

PullRequestReviewEvent

push eventAzure/azure-sdk-for-js

abc516

commit sha 1ca73290d9c4dd3187760a619f4f31f78dc2b795

fix schema registry lint errors (#12011) * fix eslint errors in schema-registry-avro package * fix eslint errors for azure/schema-registry package * adjust package.json to treat any new schemaRegistry eslint errors as a hard failure in CI * fix CI issue with schema registry unit tests Co-authored-by: Anton Cataldi <anton.cataldi@insight.com>

view details

push time in a day

issue closedAzure/azure-sdk-for-js

Fix ESLint errors for Schemaregistry

Fix lint errors found in schemaregistry packages by ESLint. Following are the steps to run ESLint for schemaregistry packages and reproduce this issue.

  1. Set up your dev environment if not already done so as mentioned here
  2. Go to <repo root>/sdk/schemaregistry/<package-name>
  3. run rushx lint
  4. Command in step 2 generates an html report in directory <repo root>/sdk/schemaregistry/<package-name> with name ends with lintReport.html
  5. All lint errors found in this package is listed on html report.

Once all known issues are resolved, below change is required in package.json file in package root <repo root>/sdk/schemaregistry/<package-name> to treat any new lint regression as hard failure in CI.

  • Remove following snippet from lint command in package.json -f html -o template-lintReport.html || exit 0

Note: HTML report name prefix may be different for each package name to differentiate the report for each package.

closed time in a day

praveenkuttappan
PullRequestReviewEvent

pull request commentAzure/azure-sdk-for-js

Servicebus remove viapartitionkey

/azp run js - servicebus - tests

mohsin-mehmood

comment created time in a day

Pull request review commentAzure/azure-sdk-for-js

[service-bus] Make subscribe() more resilient against errors.

 export class StreamingReceiver extends MessageReceiver {    * @param connectionDidDisconnect Whether this method is called as a result of a connection disconnect.
richardpark-msft

comment created time in a day

Pull request review commentAzure/azure-sdk-for-js

[service-bus] Make subscribe() more resilient against errors.

 export class StreamingReceiver extends MessageReceiver {        const translatedError = receiverError ? translate(receiverError) : receiverError; -      // Track-1-      //   - We should only attempt to reopen if either no error was present,-      //     or the error is considered retryable.-      // Track-2-      //  Reopen-      //   - If no error was present-      //   - If the error is a MessagingError and is considered retryable-      //   - Any non MessagingError because such errors do not get-      //     translated by `@azure/core-amqp` to a MessagingError-      //   - More details here - https://github.com/Azure/azure-sdk-for-js/pull/8580#discussion_r417087030-      const shouldReopen =-        translatedError instanceof MessagingError ? translatedError.retryable : true;--      // Non-retryable errors that aren't caused by disconnect-      // will have already been forwarded to the user's error handler.-      // Swallow the error and return quickly.-      if (!shouldReopen && !causedByDisconnect) {-        logger.logError(-          translatedError,-          "%s Encountered a non retryable error on the receiver. Cannot recover receiver. encountered error",-          this.logPrefix,-          this.name,-          this.address-        );-        return;-      }+      logger.logError(+        translatedError,+        `${this.logPrefix} Encountered an error on the connection. Reinitializing receiver.`+      ); -      // Non-retryable errors that are caused by disconnect-      // haven't had a chance to show up in the user's error handler.-      // Rethrow the error so the surrounding try/catch forwards it appropriately.-      if (!shouldReopen && causedByDisconnect) {-        logger.logError(-          translatedError,-          "%s Encountered a non retryable error on the connection. Cannot recover receiver.",-          this.logPrefix,-          this.name,-          this.address-        );-        throw translatedError;+      if (translatedError && this._onError) {+        this._onError({+          errorSource: "receive",+          entityPath: this.entityPath,+          error: translatedError,+          fullyQualifiedNamespace: this._context.config.host+        });       }        // shall retry forever at an interval of 15 seconds if the error is a retryable error       // else bail out when the error is not retryable or the operation succeeds.
      // shall retry forever.
richardpark-msft

comment created time in a day

Pull request review commentAzure/azure-sdk-for-js

[service-bus] Make subscribe() more resilient against errors.

 export class StreamingReceiver extends MessageReceiver {        const translatedError = receiverError ? translate(receiverError) : receiverError; -      // Track-1-      //   - We should only attempt to reopen if either no error was present,-      //     or the error is considered retryable.-      // Track-2-      //  Reopen-      //   - If no error was present-      //   - If the error is a MessagingError and is considered retryable-      //   - Any non MessagingError because such errors do not get-      //     translated by `@azure/core-amqp` to a MessagingError-      //   - More details here - https://github.com/Azure/azure-sdk-for-js/pull/8580#discussion_r417087030-      const shouldReopen =-        translatedError instanceof MessagingError ? translatedError.retryable : true;--      // Non-retryable errors that aren't caused by disconnect-      // will have already been forwarded to the user's error handler.-      // Swallow the error and return quickly.-      if (!shouldReopen && !causedByDisconnect) {-        logger.logError(-          translatedError,-          "%s Encountered a non retryable error on the receiver. Cannot recover receiver. encountered error",-          this.logPrefix,-          this.name,-          this.address-        );-        return;-      }+      logger.logError(+        translatedError,+        `${this.logPrefix} Encountered an error on the connection. Reinitializing receiver.`+      ); -      // Non-retryable errors that are caused by disconnect-      // haven't had a chance to show up in the user's error handler.-      // Rethrow the error so the surrounding try/catch forwards it appropriately.-      if (!shouldReopen && causedByDisconnect) {-        logger.logError(-          translatedError,-          "%s Encountered a non retryable error on the connection. Cannot recover receiver.",-          this.logPrefix,-          this.name,-          this.address-        );-        throw translatedError;+      if (translatedError && this._onError) {+        this._onError({+          errorSource: "receive",+          entityPath: this.entityPath,+          error: translatedError,+          fullyQualifiedNamespace: this._context.config.host+        });       }        // shall retry forever at an interval of 15 seconds if the error is a retryable error       // else bail out when the error is not retryable or the operation succeeds.-      const config: RetryConfig<void> = {-        operation: () =>-          this.init(-            // provide a new name to the link while re-connecting it. This ensures that-            // the service does not send an error stating that the link is still open.-            true-          ).then(() => {-            this._receiverHelper.addCredit(this.maxConcurrentCalls);-            return;-          }),-        connectionId: connectionId,-        operationType: RetryOperationType.receiverLink,-        retryOptions: this._retryOptions,-        connectionHost: this._context.config.host-      };-      // Attempt to reconnect. If a non-retryable error is encountered,-      // retry will throw and the error will surface to the user's error handler.-      await retry<void>(config);+      await this.init({+        // provide a new name to the link while re-connecting it. This ensures that+        // the service does not send an error stating that the link is still open.+        useNewName: true,+        connectionId: this._context.connectionId,+        onError: (args) => this._onError && this._onError(args)+      });++      this._receiverHelper.addCredit(this.maxConcurrentCalls);     } catch (err) {       logger.logError(         err,         "%s An error occurred while processing detached()",         this.logPrefix,         this.name,+         this.address       );       if (typeof this._onError === "function") {

We added this part in #6336 to ensure that the user's error handler is called when the retry attempts are exhausted. Now that init() runs forever and we call user's error handler from in there, do we need this here?

richardpark-msft

comment created time in a day

Pull request review commentAzure/azure-sdk-for-js

[service-bus] Make subscribe() more resilient against errors.

 export class StreamingReceiver extends MessageReceiver {        const translatedError = receiverError ? translate(receiverError) : receiverError; -      // Track-1-      //   - We should only attempt to reopen if either no error was present,-      //     or the error is considered retryable.-      // Track-2-      //  Reopen-      //   - If no error was present-      //   - If the error is a MessagingError and is considered retryable-      //   - Any non MessagingError because such errors do not get-      //     translated by `@azure/core-amqp` to a MessagingError-      //   - More details here - https://github.com/Azure/azure-sdk-for-js/pull/8580#discussion_r417087030-      const shouldReopen =-        translatedError instanceof MessagingError ? translatedError.retryable : true;--      // Non-retryable errors that aren't caused by disconnect-      // will have already been forwarded to the user's error handler.-      // Swallow the error and return quickly.-      if (!shouldReopen && !causedByDisconnect) {-        logger.logError(-          translatedError,-          "%s Encountered a non retryable error on the receiver. Cannot recover receiver. encountered error",-          this.logPrefix,-          this.name,-          this.address-        );-        return;-      }+      logger.logError(+        translatedError,+        `${this.logPrefix} Encountered an error on the connection. Reinitializing receiver.`+      ); -      // Non-retryable errors that are caused by disconnect-      // haven't had a chance to show up in the user's error handler.-      // Rethrow the error so the surrounding try/catch forwards it appropriately.-      if (!shouldReopen && causedByDisconnect) {-        logger.logError(-          translatedError,-          "%s Encountered a non retryable error on the connection. Cannot recover receiver.",-          this.logPrefix,-          this.name,-          this.address-        );-        throw translatedError;+      if (translatedError && this._onError) {+        this._onError({

When there is an error on the AMQP link or session, we call the user's error handler. This is soon followed by the AMQP link or session closing, which is when we call the onDetached() method. With this change, we end up calling the user's error handler twice for the same error.

richardpark-msft

comment created time in a day

Pull request review commentAzure/azure-sdk-for-js

[service-bus] Make subscribe() more resilient against errors.

 export class StreamingReceiver extends MessageReceiver {     await this._receiverHelper.suspend();   } -  async init(useNewName: boolean, abortSignal?: AbortSignalLike): Promise<void> {-    const options = this._createReceiverOptions(useNewName, this._getHandlers());-    await this._init(options, abortSignal);+  private static wrapRetryOperation(+    entityPath: string,+    fullyQualifiedNamespace: string,+    fn: () => Promise<void>,+    onError?: OnError+  ) {+    return async () => {+      try {+        await fn();+      } catch (err) {+        onError &&+          onError({

This would mean that we would calling the user's error handler for every error that occurs. For retryable errors, previously, we would do this only if the retry attempts had exhausted. Are we sure that the increased noise is what we want?

richardpark-msft

comment created time in a day

Pull request review commentAzure/azure-sdk-for-js

[service-bus] Make subscribe() more resilient against errors.

 export class StreamingReceiver extends MessageReceiver {     await this._receiverHelper.suspend();   } -  async init(useNewName: boolean, abortSignal?: AbortSignalLike): Promise<void> {-    const options = this._createReceiverOptions(useNewName, this._getHandlers());-    await this._init(options, abortSignal);+  private static wrapRetryOperation(+    entityPath: string,+    fullyQualifiedNamespace: string,+    fn: () => Promise<void>,+    onError?: OnError+  ) {+    return async () => {+      try {+        await fn();+      } catch (err) {+        onError &&+          onError({+            error: err,+            errorSource: "receive",+            entityPath,+            fullyQualifiedNamespace+          });++        if (err.name !== "AbortError") {+          err.retryable = true;

Are we sure we want to update the same error rather than create a new error object and throw that? Since we pass the error to user's error callback, they might be hanging on to it and changing it on them might not be a good idea.

richardpark-msft

comment created time in a day

Pull request review commentAzure/azure-sdk-for-js

[service-bus] Make subscribe() more resilient against errors.

 export class StreamingReceiver extends MessageReceiver {     await this._receiverHelper.suspend();   } -  async init(useNewName: boolean, abortSignal?: AbortSignalLike): Promise<void> {-    const options = this._createReceiverOptions(useNewName, this._getHandlers());-    await this._init(options, abortSignal);+  private static wrapRetryOperation(+    entityPath: string,+    fullyQualifiedNamespace: string,+    fn: () => Promise<void>,+    onError?: OnError+  ) {+    return async () => {+      try {+        await fn();+      } catch (err) {+        onError &&+          onError({+            error: err,+            errorSource: "receive",+            entityPath,+            fullyQualifiedNamespace+          });++        if (err.name !== "AbortError") {+          err.retryable = true;+        }++        // once we're at this point where we can spin up a connection we're past the point+        // of fatal errors like the connection string just outright being malformed, for instance.+        throw err;+      }+    };+  }++  async init(+    args: { useNewName: boolean; connectionId: string; onError: OnError } & Pick<+      OperationOptionsBase,+      "abortSignal"+    >+  ) {+    while (true) {+      const config: RetryConfig<void> = {+        operation: StreamingReceiver.wrapRetryOperation(+          this.entityPath,+          this._context.config.host,+          () => this._initOnce(args),+          args.onError+        ),+        connectionId: args.connectionId,+        operationType: RetryOperationType.receiverLink,+        // even though we're going to loop infinitely we allow them to control the pattern we use on each+        // retry run. This lets them toggle things like exponential retries, etc..

Did we check with @JoshLove-msft and others if we are being consistent in our approach across languages here?

richardpark-msft

comment created time in a day

Pull request review commentAzure/azure-sdk-for-js

[service-bus] Make subscribe() more resilient against errors.

 export abstract class MessageReceiver extends LinkEntity<Receiver> {    * @param causedByDisconnect Indicator of whether the error is caused by the connection disconnecting.    * In this case, the receiver/session error events do not get fired.
richardpark-msft

comment created time in a day

Pull request review commentAzure/azure-sdk-for-js

[service-bus] Make subscribe() more resilient against errors.

 const systemErrorFieldsToCopy: (keyof Omit<NetworkSystemError, "name" | "message   "syscall" ]; +/**+ * AMQP messaging error codes+ */+export type MessageErrorCodes =

Is there any TS magic we can do to ensure that the ErrorNameConditionMapper and ConditionErrorNameMapper are tied to these codes so that if there are any additions done to one of these and not all three would cause errors?

richardpark-msft

comment created time in a day

PullRequestReviewEvent
PullRequestReviewEvent

issue commentAzure/azure-sdk-for-js

[Storage] Cleanup - Post Preview 3

@ljian3377 I would recommend that you do another review of the tasks above and create a new issue for ones that you see are still applicable.

HarshaNalluru

comment created time in a day

issue commentgolang/vscode-go

installation: allow to use different build settings for tools installation

Also, the new proposal does not have a counterpart to go.toolsGopath. What is our answer for folks who used this to ensure that the Go tools used by the extension dont pollute their gopath?

hyangah

comment created time in a day

issue commentgolang/vscode-go

installation: allow to use different build settings for tools installation

go.toolsEnvVars applies to all the Go tools that are run by the extension. In the new proposal, you have flags. Do you plan to apply these flags to all the Go tools or are you thinking of these flags to apply only to the go cmd?

hyangah

comment created time in a day

Pull request review commentAzure/azure-sdk-for-js

[Service Bus] ATOM API - Update `update` methods with better param names/types and rephrased docs 👓

 export class ServiceBusAdministrationClient extends ServiceClient {   /**    * Updates the queue based on the queue properties provided.    * All queue properties must be set even though only a subset of them are actually updatable.-   * Therefore, the suggested flow is to use `getQueue()` to get the complete set of queue properties,-   * update as needed and then pass it to `updateQueue()`.+   * Therefore, the suggested flow is to use `getQueue()` to get the complete set of queue properties(accompanied by the _response),

Then , I would rephrase to avoid calling out inner details like _response

Therefore, the suggested flow is to use the output from getQueue(), update the desired properties in it, and then pass the modified object to updateQueue().

HarshaNalluru

comment created time in a day

PullRequestReviewEvent

Pull request review commentAzure/azure-sdk-for-js

[Service Bus] ATOM API - Update `update` methods with better param names/types and rephrased docs 👓

 export class ServiceBusAdministrationClient extends ServiceClient {     ruleExists(topicName: string, subscriptionName: string, ruleName: string, operationOptions?: OperationOptions): Promise<boolean>;     subscriptionExists(topicName: string, subscriptionName: string, operationOptions?: OperationOptions): Promise<boolean>;     topicExists(topicName: string, operationOptions?: OperationOptions): Promise<boolean>;-    updateQueue(queue: QueueProperties, operationOptions?: OperationOptions): Promise<WithResponse<QueueProperties>>;-    updateRule(topicName: string, subscriptionName: string, rule: RuleProperties, operationOptions?: OperationOptions): Promise<WithResponse<RuleProperties>>;-    updateSubscription(subscription: SubscriptionProperties, operationOptions?: OperationOptions): Promise<WithResponse<SubscriptionProperties>>;-    updateTopic(topic: TopicProperties, operationOptions?: OperationOptions): Promise<WithResponse<TopicProperties>>;+    updateQueue(queuePropertiesWithResponse: WithResponse<QueueProperties>, operationOptions?: OperationOptions): Promise<WithResponse<QueueProperties>>;

Lets do that.

HarshaNalluru

comment created time in a day

PullRequestReviewEvent

issue closedAzure/azure-sdk-for-js

[service-bus] API: move settlement/renewLock from message object to Receiver

As part of an internal API review we've decided that the settlement and lock renew methods are located in two separate spots across our SDKs - on the Receiver (Java, C#) or on the ServiceBusMessage (Python, JavaScript).

Rather than allowing these SDKs to diverge we've chosen to unite them and to put the methods onto the Receiver object. This also aligns with the idioms we've applied across our other packages in the Azure SDK - generally, data is not "smart" and doesn't carry actions.

There are other potential benefits in the future, like allowing the ability to process multiple items at a time, etc... None of these are coming in any planned version of the SDK but they do exist as a potential API extension in the future.

The names of the methods will change slightly to indicate they are message specific:

Methods:

  • renewMessageLock
  • completeMessage/abandonMessage/deferMessage/deadLetterMessage

closed time in a day

richardpark-msft

issue commentAzure/azure-sdk-for-js

[Service Bus] Browser requests do not work unless web security is disabled

What affect does this have on users writing web applications? Is the problem only when they try to add tests for their code?

ramya0820

comment created time in a day

Pull request review commentAzure/azure-sdk-for-js

Servicebus remove viapartitionkey

 export class ManagementClient extends LinkEntity<RequestResponseLink> {         if (item.partitionKey) {           entry["partition-key"] = item.partitionKey;         }-        if (item.viaPartitionKey) {-          entry["via-partition-key"] = item.viaPartitionKey;-        }

@mohsin-mehmood This comment is applicable to all other places from where we are deleting the code for viaPartitionKey. Can you comment such code instead of deleting it?

Also, I see the below comment you added

// Will be required later for implementing Transactions feature of Service Bus.

This uses the markdown syntax for links which we dont need in source code. You can instead use

// Will be required later for implementing Transactions

mohsin-mehmood

comment created time in a day

PullRequestReviewEvent

Pull request review commentAzure/azure-sdk-for-js

Acataldi/10779 fix schema registry lint errors

 const testGroup = "azsdk_js_test_group"; const testSchemaIds = [   "{773E17BE-793E-40B0-98F1-0A6EA3C11895}",   "{DC7EF290-CDB1-4245-8EE8-3DD52965866E}"-].map((x) => x.replace(/[\{\-\}]/g, ""));+].map((x) => x.replace(/[{\-}]/g, ""));

@abc516 Can you share which linting rule failure is this change fixing?

@nguerrera, Do you recall what exactly are we trying to replace here and why?

abc516

comment created time in a day

PullRequestReviewEvent

issue commentAzure/azure-sdk-for-js

[Service Bus] Limits on ServiceBusMessageBatch

Do we know if Event Hubs has a similar limitation?

HarshaNalluru

comment created time in 3 days

Pull request review commentAzure/azure-sdk-for-js

Servicebus remove viapartitionkey

 export class ManagementClient extends LinkEntity<RequestResponseLink> {         if (item.partitionKey) {           entry["partition-key"] = item.partitionKey;         }-        if (item.viaPartitionKey) {-          entry["via-partition-key"] = item.viaPartitionKey;-        }

Since we will be adding this back in the near future, I wonder if it is better to comment the code out rather than delete it. @HarshaNalluru, @richardpark-msft Thoughts?

mohsin-mehmood

comment created time in 4 days

PullRequestReviewEvent

Pull request review commentAzure/azure-sdk-for-js

Servicebus remove viapartitionkey

 - `ServiceBusSender.scheduleMessages` method signature updated: `scheduledEnqueueTimeUtc` and `messages` parameters are swapped. - Interfaces corresponding to the returned responses from the methods under the `ServiceBusAdministrationClient` such as `NamespacePropertiesResponse`, `QueueResponse`, `TopicRuntimePropertiesResponse` have been removed in favor of using generic type `WithResponse<T>` for a cleaner API surface.   [PR 10491](https://github.com/Azure/azure-sdk-for-js/pull/10491)+- `viaPartitionKey` property of interface `ServiceMessageBus` has been removed.
- `viaPartitionKey` property of interface `ServiceMessageBus` has been removed until we implement the [Transactions feature of Service Bus](https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-transactions).
mohsin-mehmood

comment created time in 4 days

PullRequestReviewEvent

delete branch ramya-rao-a/azure-sdk-for-js

delete branch : receiver-overloads

delete time in 4 days

push eventAzure/azure-sdk-for-js

Ramya Rao

commit sha 433905beccf28b095a3261e1fd8692a03f9fcd4d

Remove receiver overloads meant to hide settlement methods when using ReceiveAndDelete mode (#12014)

view details

push time in 4 days

PR merged Azure/azure-sdk-for-js

Reviewers
Remove receiver overloads meant to hide settlement methods when using ReceiveAndDelete mode Service Bus auto-merge

This is a follow up for the changes in the PR #11962

In #11926 we decided not to have the overloads for createReceiver, acceptSession and acceptNextSession methods that would allow us to hide the message settlement methods if a TypeScript user is using ReceiveAndDelete mode. This PR removes the said overloads that are remnants of #11962

+85 -244

3 comments

7 changed files

ramya-rao-a

pr closed time in 4 days

issue commentAzure/azure-sdk-for-java

[FEATURE REQ] receiveMessages() call in async client should continue to try to receive messages unless stopped by the user

Please check with @JoshLove-msft if the forever loop applies to when working with single sessions or not. There is a concern that when we get an error on the receiver link for sessions, we should not attempt to recover and rather inform the user right away to let them decide if they want to continue with the session or move to another session.

The forever loop applies to the case when working with multiple sessions though, because the user has already opted into the model of moving to the next available session when one of the links fail.

cc @hemanttanwar, @srnagar, @YijunXieMS

ramya-rao-a

comment created time in 4 days

issue commentAzure/azure-sdk-for-java

For-ever-loop - async receiveMessages never stops

@hemanttanwar Can we close this in favor of #16084?

hemanttanwar

comment created time in 4 days

push eventramya-rao-a/azure-sdk-for-js

Ramya Achutha Rao

commit sha b8c4ad74b121b1351cb5d4ba622c79ce5c41017d

Update jsdocs for createReceiver overload for subscriptions

view details

push time in 4 days

push eventramya-rao-a/azure-sdk-for-js

Ramya Achutha Rao

commit sha 02ee5a1bcbc5fe42a043b8825f049e9630a87a9e

max delivery count on subscription

view details

push time in 4 days

push eventramya-rao-a/azure-sdk-for-js

Ramya Achutha Rao

commit sha 34109622de6ae8c51d0bf093ea9886af3ad95de5

Undo unintentional formatiing changes

view details

Ramya Achutha Rao

commit sha 5d6e0be5bac84d7490fd0567728b5ae1840e95c8

Clarify receive modes

view details

push time in 4 days

push eventramya-rao-a/azure-sdk-for-js

Azure SDK Bot

commit sha 2a6d4396257dfb52a0858228d7467793d1992b31

Fix create-pull-request bug (#12001) Co-authored-by: Chidozie Ononiwu <chononiw@microsoft.com>

view details

Chidozie Ononiwu

commit sha 25db351992e409603e3be263b09337515a747e40

Switch from testpipeline variable to parameters (#11986)

view details

Harsha Nalluru

commit sha 91b20e398ae1df59d7e7911dfea560130ee3bf97

[Service Bus] Generic types for `Response`s for a cleaner API surface (#10491) ![image](https://user-images.githubusercontent.com/10452642/91238146-39d52c00-e6f1-11ea-9625-1655a8e8f9c8.png) ![image](https://user-images.githubusercontent.com/10452642/91238194-53767380-e6f1-11ea-9387-4ab00e6c5d00.png)

view details

Mohsin Mehmood

commit sha 0bc0c6c98fe889582e1b4ef25eccd162b4c74ac1

[servicebus] CreateReceiverOptions, AcceptSessionOptions renamed (#11993)

view details

Ramya Achutha Rao

commit sha dfe0767177ab3f6a199de644a022c340f4188c1a

Merge remote-tracking branch 'origin' into pr/ramya-rao-a/12014-1

view details

push time in 4 days

Pull request review commentAzure/azure-sdk-for-js

[Service Bus] ATOM API - Update `update` methods with better param names/types and rephrased docs 👓

 export class ServiceBusAdministrationClient extends ServiceClient {     ruleExists(topicName: string, subscriptionName: string, ruleName: string, operationOptions?: OperationOptions): Promise<boolean>;     subscriptionExists(topicName: string, subscriptionName: string, operationOptions?: OperationOptions): Promise<boolean>;     topicExists(topicName: string, operationOptions?: OperationOptions): Promise<boolean>;-    updateQueue(queue: QueueProperties, operationOptions?: OperationOptions): Promise<WithResponse<QueueProperties>>;-    updateRule(topicName: string, subscriptionName: string, rule: RuleProperties, operationOptions?: OperationOptions): Promise<WithResponse<RuleProperties>>;-    updateSubscription(subscription: SubscriptionProperties, operationOptions?: OperationOptions): Promise<WithResponse<SubscriptionProperties>>;-    updateTopic(topic: TopicProperties, operationOptions?: OperationOptions): Promise<WithResponse<TopicProperties>>;+    updateQueue(queuePropertiesWithResponse: WithResponse<QueueProperties>, operationOptions?: OperationOptions): Promise<WithResponse<QueueProperties>>;

What about just queue?

HarshaNalluru

comment created time in 4 days

more