### Packages impacted by this PR
`@azure-tools/test-perf`
### Describe the problem that is addressed by this PR
Making perf package public for consumption outside this repo.
This marks the initial release of the `@azure-tools/test-perf` library
to npm, providing a robust test utility framework that assists with the
performance testing of Azure SDKs for JS/TS.
### Key Concepts
1. **Introduction of PerfTest**: A test utility designed to execute
performance and stress tests for Azure SDK for JavaScript packages.
2. **Test Execution**: Tests are run asynchronously, influenced by
parameters like duration, iterations, and parallelism.
3. **Command Line Parameters**: Utilizes `minimist` for parsing command
line options into a `PerfOptionDictionary<string>` for test
configuration.
4. **Default Options**: Includes standard parameters such as `help`,
`no-cleanups`, `parallel`, `duration`, `warmup`, `iterations`,
`no-cleanup`, and `milliseconds-to-log`.
5. **Test Lifecycle**: Tests run repeatedly within the specified
`duration` and `iterations`, with a `warmup` period for runtime
optimization.
6. **Setup and Cleanup**: Features `globalSetup`/`globalCleanup` methods
for CPU-level preparation and `setup`/`cleanup` methods for
instance-specific state management.
### Packages impacted by this PR
@azure/core-amqp
### Issues associated with this PR
N/A
### Describe the problem that is addressed by this PR
The errors thrown between retries could differ and the customer wouldn't
be able to know them unless they enable logging.
### What are the possible designs available to address the problem? If
there are more than one possible design, why was the one in this PR
chosen?
Another design is to provide an error handler callback to be called on
all errors but since it is an extreme measure, we can revisit this
latter if we get an ask for it.
### Are there test cases added in this PR? _(If not, why?)_
N/A
### Provide a list of related PRs _(if any)_
N/A
### Command used to generate this PR:**_(Applicable only to SDK release
request PRs)_
### Checklists
- [x] Added impacted package name to the issue description
- [ ] Does this PR needs any fixes in the SDK Generator?** _(If so,
create an Issue in the
[Autorest/typescript](https://github.com/Azure/autorest.typescript)
repository and link it here)_
- [x] Added a changelog (if necessary)
---------
Co-authored-by: Jeff Fisher <jeffish@microsoft.com>
Looks like Google updated their URLs for chrome for testing downloads,
planning to retire the `hdgedl.me.gvt1.com...` URLs with
`storage.googleapis.com` URLs
It may have been deprecated for quite some time, but looks like as of
last night the old URLs have died, returning 500 instead.
As a result, puppeteer postinstall breaks the build
According to https://github.com/puppeteer/puppeteer/issues/11967
puppeteer 22.2.0 already uses the new URLs which
we can easily upgrade to.
This PR bumps the min-version to 22.2.0 across the board.
We added a timeout of 200 milliseconds on credit draining before
returning from `receiveMessages()`. There's customer report that
indicates this timeout is aggressive in environment with slow network
and caused link churn because we close link when draining times out to
avoid going into a bad state.
This PR changes the wait time to the max of 200 ms and the remaining
portion of the `maxWaitTimeInMs` option that is passed to
`receiveMessages()`, allowing customer to customize the time out
indirectly.
### Packages impacted by this PR
`@azure/service-bus`
### Issues associated with this PR
#28023
### What are the possible designs available to address the problem? If
there are more than one possible design, why was the one in this PR
chosen?
- exposing an option to set drain timeout. This is not desired since
waiting for draining is an internal implementation detail
- increase 200 ms to some other higher value. It's not possible to
determin a best value for this as environments are different.
- adaptive behavior that adjust the wait time dynamically based on how
frequently the link was closed due to time out. This can leads to
complicate logic.
- Switch to use esm4mocha loader by default
- Add `--use-esm-workaround=true` to packages that need more work
(mostly due to usage of `__dirname` that is no longer available in ESM)
- Change some usage of `__dirname` to `"."` when possible
- [esm4mocha] only transform modules whose format is changed
- [load-testing-rest] update tsconfig.json to be consistent with other
packages
Currently most of our '*.js' tests and sources under dist-esm/ are
transformed by `esm` package (now outdated and archived) before being
feeded to Mocha because when a package.json has `"type":
"commonjs"` thus Mocha treats `.js` files as CommonJS.
This PR takes another approach by telling Mocha that the loaded modules
under dist-esm/ are ESM via a custom loader (`esm4mocha.mjs`).
This is done mainly in two parts:
1. During resolving, this loader checks the path of resolved modules and
if it includes `"dist-esm/"` we set the format of the resolved module to
`"module"`.
2. Also in ESM the full extension is required for relative modules in
import/export declarations, so a transformation is applied
to add `".js"` extension to relative imports/exports on the fly when
loading the module.
ServiceBus integration-test:node script has been updated to use this
approach. For now, the dev-tool command is unrolled and the old
workaround is replaced by the new one:
```diff
- -r ../../../common/tools/esm-workaround -r esm
+ --loader=../../../common/tools/esm4mocha.mjs
```
In the future, the dev-tool command would be updated to use the new
workaround for the majority of our packages.
### Packages impacted by this PR
- @azure/event-hubs
- @azure/service-bus
### Issues associated with this PR
- https://github.com/Azure/azure-sdk-for-js/security/dependabot/49
### Describe the problem that is addressed by this PR
Updates with the latest `https-proxy-agent` which does not have the
vulnerability.
### What are the possible designs available to address the problem? If
there are more than one possible design, why was the one in this PR
chosen?
### Are there test cases added in this PR? _(If not, why?)_
### Provide a list of related PRs _(if any)_
### Command used to generate this PR:**_(Applicable only to SDK release
request PRs)_
### Checklists
- [x] Added impacted package name to the issue description
- [ ] Does this PR needs any fixes in the SDK Generator?** _(If so,
create an Issue in the
[Autorest/typescript](https://github.com/Azure/autorest.typescript)
repository and link it here)_
- [ ] Added a changelog (if necessary)
by running `rush add -m --dev -p puppeteer@^22.0.0`
- adjust core-xml test due puppeteer switched from Chromium to Chrome
- ignore Accept-Language headers for browser playback tests
Resolves https://github.com/Azure/azure-sdk-for-js/issues/25790
This change migrates every package to the latest major version of
identity in order to ensure we can catch any regressions earlier in the
development process.
I chose to upgrade the samples' package.json as well - but happy to
revert that if there are objections.
***NO_CI***
Our tests use the type `Mocha.Context` when they need to pass the test context
to test recorder. However, without a dev dependency on `@types/mocha`
compilation may fail when recorder constructor is changed from taking a
`Mocha.Test` to taking an interface that is compatible.
This change ensures the dev depedency on `@types/mocha` too if there's a dev
dependency on `mocha`.
***NO_CI***
Though both are correct (US version and non-US version), our repo mostly
uses "License". This PR updates the occurrance of "Licence" with
"License" to be consistent and make our linter happy.
***NO_CI***
Latest versions of prettier now correctly formats `tsconfig.json`, which results
in differences with previous version of 3.1.1 in pnpm-lock.yaml. This is failing
the automated rush update pipeline because `check-format` fails with version
3.2.4.
This includes changes of
- bumping prettier version to ^3.2.4
- running `rush format`
Following the .NET fix
https://github.com/Azure/azure-sdk-for-net/pull/40916
### Packages impacted by this PR
`@azure/core-amqp`, `@azure/service-bus`
### Issues associated with this PR
#28121
### Describe the problem that is addressed by this PR
When a message is received, if the absolute expiry time was set on the
AMQP message, the TTL should be set using the difference between the
absolute expiry time and the message creation time. This works around
the limitation of the AMQP spec where a value larger than 49 days in
milliseconds cannot be sent over the wire as the field is a uint32. Also
currently JS SDK throws an error if a TTL value of larger than 49 days
in milliseconds value is set on messages to send.
Both core-amqp and service-bus are fixed because service-bus has its own
`fromRheaMessage` and `toRheaMessage` to enable configuring JSON body
parsing behavior and Date conversion.
***NO_CI***
- remove dev dependency `prettier` from non-tool packages when possible and
update them to run vendored prettier for `check-format` and `format` scripts
- upgrade rest of packages to prettier v3
- run `rush format` for all rush packages
This is a follow-up to https://github.com/Azure/azure-sdk-for-js/pull/28127 to
move the rest of repo to prettier v3.
We plan to deprecate `@azure/core-http` soon and it has been maintained
and released from `sotrage/stable` branch for a while. This PR removes
it from main branch of the repo.
- remove sdk/core/core-http directory
- update references to core-http in documentation
- publish communication-sms samples so previous change of moving from
core-http to core-util is reflected.
Otherwise this could occur:
- message handler completes
- one credit added
- while we are completing the message, the same message arrives again
since there's one credit, and the message hasn't been settled.
### Packages impacted by this PR
@azure/service-bus
Currently in session receiver, we fire-and-forget user's error handler
instead of awaiting it. This is causing problems when customer want to
modify state in message handler, and want to roll back in case of error
as currently we would carry on to abandon the message when error
happens, then add credit. The same message could arrive and processed,
while the error handling is still going on.
This PR changes it to wait for user error handler before proceeding.
This behavior of awaiting user error handler is in line with our
streaming receiver and other languages.
Some files are not formated in commits that were merged without CI. This
PR updates them with the result from `rush format`, and also fixes
`format` script for ts-http-runtime
It's possible that after we create the sender link, but before using it
to send message, the link gets closed for example due to bad network
condition. Our current code would throw a type error when accessing
`send()` method of the undefined `link`. The error is not retryable.
This PR checks for valid link again before calling `link.send()` and
throw an new retryable client error.
***NO_CI***
The combination of `nyc` + `esm` is broken in latest versions of
NodeJS (https://github.com/istanbuljs/nyc/issues/1530#issuecomment-1773403365).
Since `esm` package is no longer actively maintained and its repo is archived,
it's less likely that the issue will be fixed soon.
This change switches to use another code coverage tool `c8` which is not
affected. `c8` respects `.nycrc` config files so those are not renamed.
Service Bus live tests failed due to the switched ordering of parameter
type checking for `messages` and `scheduledEnqueueTimeUtc`. Even though
this is unlikely a real world scenario where users would passing in
undefined `messages` before a valid `scheduledEnqueueTimeUtc`, this PR
restores the old order to presrve the existing behavior.
to `scheduleMessages()`.
The service ignores the value when it is not valid. This may surprise
JavaScript developers who pass in a datetime string and expect it to
work. This adds an `instanceof` check to only accept `Date` instances
[Successful live
test](https://dev.azure.com/azure-sdk/internal/_build/results?buildId=3150973&view=results)
### Packages impacted by this PR
@azure/service-bus
### Issues associated with this PR
https://github.com/Azure/azure-sdk-for-js/issues/26665
### Describe the problem that is addressed by this PR
Upgrade rollup from v2 to v3
### What are the possible designs available to address the problem? If
there are more than one possible design, why was the one in this PR
chosen?
N/A
### Are there test cases added in this PR? _(If not, why?)_
N/A
### Provide a list of related PRs _(if any)_
https://github.com/Azure/azure-sdk-for-js/pull/27305
### Command used to generate this PR:**_(Applicable only to SDK release
request PRs)_
### Checklists
- [x] Added impacted package name to the issue description
- [ ] Does this PR needs any fixes in the SDK Generator?** _(If so,
create an Issue in the
[Autorest/typescript](https://github.com/Azure/autorest.typescript)
repository and link it here)_
- [ ] Added a changelog (if necessary)
***NO_CI***
- update engine.node to >=16.0.0 in package.json
- update @types/node version to ^16.0.0
- update dev-tool sample's MIN_SUPPORTED_NODE_VERSION to 16
- update eslint-plugin's rules and tests related to engine.node version
- remove TextEncoder and TextDecoder stubs as they are now on global object
- fix tests compiler error due to better typings in v16
- update some README files to not reference version like 14.x.x
Related: issue #9775, #27010
This PR fixed the following timing issue when trying to establish link
for next session but there are none available.
what's happening is
- SDK is trying to create a link for next avaiable session
(`options.source.filter: { com.microsoft:session-filter': undefined }`)
- Because no sessions are available, after one minute, a link is
established, but with `"source":null,"target":null`. The call to create
link resolves.
- However, the service immediately use that link to ask SDK to close the
link, with an error of `"com.microsoft:timeout"`/`The operation did not
complete within the allotted timeout of 00:00:59.9130000.`
- SDK respects the request and start acquiring a lock to close the link
- Meanwhile, SDK gets a link, nice! It will continue as the link has
been created
- SDK gets lock to close link and sets `this._link` to `undefined` and
start closing receiver and amqp session
- SDK null-check the link and throws INTERNAL ERROR
Instead of returning the link in this case, This PR checks whether we
got a session id back. If not and there's an error from service, we
rethrow the error. Some of the existing error handling is also moved
before returning the link, instead of afterwards.
### Are there test cases added in this PR? _(If not, why?)_
There's one test covers this scenario and verifies two possible errors.
28cbcd053d/sdk/servicebus/service-bus/test/public/sessionsTests.spec.ts (L81)
- along with it, `@types/mocha` version to `^10.0.0`
- add `esm` dev dependency as they are used, but not explicitly list
- use dev-tool run command for test scripts as much as possible
- fix test issue caused by Mocha behavior change around test name
- move `import "chai/register-should"` to mocha -r command line option for core
http tests
***NO_CI***
### Packages impacted by this PR
@azure/event-hubs, @azure/service-bus
### Issues associated with this PR
N/A
### Describe the problem that is addressed by this PR
Bump @azure/core-amqp dependency in both from v3 to v4.
### What are the possible designs available to address the problem? If
there are more than one possible design, why was the one in this PR
chosen?
N/A
### Are there test cases added in this PR? _(If not, why?)_
N/A
### Provide a list of related PRs _(if any)_
N/A
### Command used to generate this PR:**_(Applicable only to SDK release
request PRs)_
### Checklists
- [x] Added impacted package name to the issue description
- [ ] Does this PR needs any fixes in the SDK Generator?** _(If so,
create an Issue in the
[Autorest/typescript](https://github.com/Azure/autorest.typescript)
repository and link it here)_
- [ ] Added a changelog (if necessary)
We already have the logic in `MessageSender._trySend()`. This PR adds
the same to `ManagementClient._makeManagementRequest()` so that when the
link is not sendable, we wait for one second then check again. A
`SendBusyError` is thrown if we still cannot send messages.
### Packages impacted by this PR
`@azure/service-bus`
### Issues associated with this PR
#26855
***NO_CI***
Most of our packages, if not all, have dev dependency on `ts-node` either
directly (`mocha --require ts-node/register`) or indirectly via dev-tool (`run
test:node-ts-input`). Currently tests are running fine because mocha is able to
resolve ts-node currently. It may fail in other cases though (e.g., after
migrating a package to ESM).
This ensures `ts-node@^10.0.0` and `types/node` are included for our rush
packages.
- update `sinon` version to `^15.0.0`. The breaking changes does not
affect our usages.
- upgrade `@types/sinon` to `^10.0.0`. This reveals test issue where
mocked tokens are not compatible with `AccessToken`. This PR fixes the
tests too.
# Stress tests for Service Bus - Update
Based on the recent investigations at #25572, below are a few changes
that help run stress tests better with relevant insights.
- adds memory metrics
- doesn't track message ids, to not have memory noise
- tracks message count
# Stress tests for Event Hubs
- Adds the stress testing framework to the Event Hubs SDK.
- Adds the relevant tests from
https://gist.github.com/HarshaNalluru/2f1931ea30e8335678310053aa342db0
that have helped in the recent memory-leak investigations.
- Follows the patterns from the service-bus stress tests
- In sync with SB after
https://github.com/Azure/azure-sdk-for-js/pull/25658
- tracks message count
- tracks memory metrics
## EventHubsStressTester
- Sets up Application Insights for logging and tracking events.
- `EventHubsStressTester` class has methods for initializing the test,
taking snapshots of test progress, and ending the test.
- `loopForever` takes a function fn, a delay duration, and an optional
abort signal as arguments. The function enters a loop that calls fn
repeatedly with a delay between each call until the abort signal is
triggered or times out.
## noActivity test
- **Initialization**: The main function `scenarioNoActivity` creates
instances of Event Hubs consumer and producer clients and subscribes to
all partitions of the consumer client with handlers for processing
events, errors, initialization, and closing.
- **Execution**: The producer sends a batch of two events and starts a
loop that checks if the test duration has been reached or if any of the
subscribers have stopped running.
- **Cleanup**: If either condition is met, the loop exits and the
producer and consumer clients are closed. The stress test is ended by
calling the `endTest` method on the `stressBase` instance.
## getRuntimeProperties test
- **Initialization**: The main function `scenarioGetRuntimeProperties`
creates instances of Event Hubs consumer and producer clients and a
`stressBase` instance for stress testing.
- **Execution**: The function defines an asynchronous function `func`
that enters a loop and repeatedly calls the `getEventHubProperties`
method on the consumer client with a random delay between each call. The
function then creates an array of 100 promises that resolve when `func`
completes and waits for all promises to resolve.
- **Cleanup**: Once all promises have resolved, the producer and
consumer clients are closed and the stress test is ended by calling the
`endTest` method on the `stressBase` instance.
## checkpoint store test
- **Initialization**: The main function `scenarioCheckpointStore`
creates instances of Event Hubs consumer and producer clients, a
`stressBase` instance for stress testing, and a `BlobCheckpointStore`
instance for storing checkpoints. The consumer client subscribes to the
default consumer group with handlers for processing events, errors,
initialization, and closing.
- **Execution**: The function enters a loop that sends a batch of random
events using the producer client and waits for a random delay between
each iteration. The loop checks if the test duration has been reached or
if the subscription has stopped running.
- **Cleanup**: If either condition is met, the loop exits and the
producer and consumer clients are closed. The stress test is ended by
calling the `endTest` method on the `stressBase` instance.
---------
Co-authored-by: Deyaaeldeen Almahallawi <dealmaha@microsoft.com>
### Packages impacted by this PR
- @azure/event-hubs
### Issues associated with this PR
### Describe the problem that is addressed by this PR
Updating to latest [OTEL messaging
standards](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/semantic_conventions/messaging.md#messaging-attributes).
This is also explained in a gist from @lmolkova
[here](https://gist.github.com/lmolkova/e4215c0f44a49ef824983382762e6b92)
### What are the possible designs available to address the problem? If
there are more than one possible design, why was the one in this PR
chosen?
### Are there test cases added in this PR? _(If not, why?)_
### Provide a list of related PRs _(if any)_
- #25492
### Command used to generate this PR:**_(Applicable only to SDK release
request PRs)_
### Checklists
- [x] Added impacted package name to the issue description
- [ ] Does this PR needs any fixes in the SDK Generator?** _(If so,
create an Issue in the
[Autorest/typescript](https://github.com/Azure/autorest.typescript)
repository and link it here)_
- [ ] Added a changelog (if necessary)
### Packages impacted by this PR
- @azure/service-bus
### Issues associated with this PR
### Describe the problem that is addressed by this PR
Updating to latest [OTEL messaging
standards](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/semantic_conventions/messaging.md#messaging-attributes).
This is also explained in a gist from @lmolkova
[here](https://gist.github.com/lmolkova/e4215c0f44a49ef824983382762e6b92)
### What are the possible designs available to address the problem? If
there are more than one possible design, why was the one in this PR
chosen?
### Are there test cases added in this PR? _(If not, why?)_
### Provide a list of related PRs _(if any)_
### Command used to generate this PR:**_(Applicable only to SDK release
request PRs)_
### Checklists
- [x] Added impacted package name to the issue description
- [ ] Does this PR needs any fixes in the SDK Generator?** _(If so,
create an Issue in the
[Autorest/typescript](https://github.com/Azure/autorest.typescript)
repository and link it here)_
- [ ] Added a changelog (if necessary)
---------
Co-authored-by: Liudmila Molkova <limolkova@microsoft.com>
This is a port of PR https://github.com/Azure/azure-sdk-for-js/pull/8239
From original PR description:
>This change attempts to remove an edge case where `receiveMessages` may
hang indefinitely.
>
>Currently, once the `BatchingReceiver` (`receiveMessages`) reaches
either the `maxMessageCount` or `maxWaitTime`, it will drain any
remaining credits on the receiver link and then return the messages.
>
>However if for some reason the service was unable to report back that
credits were drained, the messages would never be returned and the
operation would appear to hang indefinitely.
>
>Now the receiver will wait a maximum of 200 ms for the service to
indicate that credits are drained. If this timeout is reached, then the
received messages are returned from `receiveMessages`.
>
>I chose 200 ms because in my local testing, it typically took ~80 ms
between when the receiver triggered a drain and when the
`receiver_drained` event was fired. This gives an additional 150%
buffer. I had considered using `newMessageWaitTimeoutInSeconds` instead,
which currently is set to 1 second, but was trying to minimize how long
we'd wait so that message locks wouldn't need to be renewed.
In addition to porting the changes, I also update some existing tests to
work well with the new behavior, and reduced their execution time by
shorten the max waiting time.
There are cases where the service doesn't respond to our drain-credit
request, or the response comes back after a long and unexpected time.
Since we are blocking on the `receiver_drained` event before resolving,
application code could be blocked indefinitely when suspending/closing.
This PR adds a timeout around credit draining, and if the time limit
expires we close the receiver then returns.
When a link is not ready for sending management request we will
initialize it
and a unique `replyTo` address is generated. The problem is the two
steps are
separate and only the link initialization is guarded by a lock to ensure
the
link is only initialized once. When multiple management requests are
made at the
same time, multiple `replyTo` addresses could be generated but only one
is
associated with the link, resulting in errors like
```
ServiceBusError: The response link '0f6cd6e7-16d1-034a-b661-5d632917cd50' was not found in the entity management node $management.
```
This PR groups the two parts into one locked operation, thus preventing
multiple
`replyTo` addresses from being generated for a new link.
- add a failing test without fix
- Move initialization code out of `_makeManagementRequest()` into a
locked block together with code to generate unique `replyTo`
instead of always adding credit of `maxMessageCount`. Otherwise, in the
case of user aborting the call then re-receive, we keep adding excessive
credits.
### Packages impacted by this PR
- devtool
- test-utils
- service-bus stress test
### Issues associated with this PR
https://github.com/Azure/azure-sdk-for-js/security/dependabot/18
### Describe the problem that is addressed by this PR
Updating minimist to fix the security issue as noted in
https://github.com/Azure/azure-sdk-for-js/security/dependabot/18
### What are the possible designs available to address the problem? If
there are more than one possible design, why was the one in this PR
chosen?
### Are there test cases added in this PR? _(If not, why?)_
### Provide a list of related PRs _(if any)_
### Command used to generate this PR:**_(Applicable only to SDK release
request PRs)_
### Checklists
- [ ] Added impacted package name to the issue description
- [ ] Does this PR needs any fixes in the SDK Generator?** _(If so,
create an Issue in the
[Autorest/typescript](https://github.com/Azure/autorest.typescript)
repository and link it here)_
- [ ] Added a changelog (if necessary)
***NO_CI***
- `@rollup/plugin-commonjs` to `^24.0.0`
- `@rollup/plugin-json` to `^6.0.0`
- `@rollup/plugin-multi-entry` to `^6.0.0`
- `rollup-plugin-polyfill-node` to `^0.12.0`
- `@rollup/plugin-inject` to `^5.0.0`
- `@rollup/plugin-replace` to `^5.0.0`
Fix notification-hubs rollup test config: now sourcemaps plugin is complaining
about .ts file. Move typescript plugin before it.
Fix service-bus to include needed rollup dependencies. It was lucky to be able
to re-use on other packages to install them but is failing in some builds.
* [ServiceBus] Add option to preserve Date type when receiving messages
For compatibility reason we convert Date properties into epoch numbers even
though the underlying rhea library supports Date type now.
This PR adds an option to keep the Date type when receiving messages. By default
we still convert properties of Date type into numbers.
* bump minor version and update CHANGELOG
* [sb] improve auto lock renew logging
previously the two cases share same log message, which can be confusing. This PR
separate them to have different log messages.
* Move negative cases first
to improve readability. Having them at the end makes it hard to relate them
with their corresponding conditions
* Format
Some errors (e.g., `MessageSizeExceeded`) would close the underlying rhea link.
Currently we have a `replyTo` property that is initialized when constructing the
management client and remains unchanged. However, this leads to the following
error when attempting to re-establish a new link:
```
InvalidOperationError: A link with the same 'attach.target.address' value '504c8ecd-6f73-1b4e-9108-d1e12fc3ac9f' address has been already registered to the entity management node $management.
```
This PR ensure that whenever we send a request, if we are going to establish a
new link, the `replyTo` property has a unique value.
Fixes#24476
Jeremy Meng
Harsha Nalluru
Maor Leger
Scott Beddall (from Dev Box)
Matthew Podwysocki
Deyaaeldeen Almahallawi
Maor Leger
Azure SDK Bot
Jeremy Meng
kazrael2119
Jeff Fisher
Mike Harder