@mikeharder found that there was a vast difference in perf for the NoOp test in track-1 vs track-2 folders. ⭐
Upon investigating, we have found that the differences in tsconfig and the different typescript versions being used for track-1 and track-2 to be the cause of the perf difference.
For a perspective, with the existing configs and TS4.1.2 for track-2 and TS4.1.5(installed globally) for track-1, the track-1 was 4 times worse in the NoOp test.
Upon changing the tsconfig for track-1 to the one we have for track-2 and adding the devDep on TS4.1.2 for track-1 similar to that of track-2, the difference was gone.
This PR attempts to fix the differences.
_(Note: Though the NoOp test had a huge perf difference, it would have been very negligible with the actual tests like downloading a blob given the work done at the SDK level and the service response time.)_
To avoid having to export random helpers from `@azure/core-rest-pipeline`, this new package is being created to house them instead. This will also allow us to share utilities between HTTP and AMQP stacks.
See #14049 for some of the motivation.
* Code gen with new swagger
* Modified the Api to be pagedIterable
* Rename model to SendSmsResult
* Swagger changes
* Exporting SendSmsResult
* Samples
* Formatting
* update swagger + auto-gen
* update method signature + tests
* formatting
* First cut - update tests
* add livetest recordings
* workaround to mock uuid for browser tests
* update recordings
* conceal repeatibilityResult
* rename request and options
* update sample
* make options bag optional
* use fake timers and check repeatability on fail
* update mocked test fix unhandled promise warning
* clean up mock
* remove unnecessary import
* update md file
* refactor + update tests to support recording
* formatting
* skip token test if browser
* update recordings
* formatting
* update recordings
* update hash + changelog
* change how we assign date for idempotency
* update tests
* change how we skip browser token test
* remove test that is failing intermittently
* make samples prettier
* change how sample is printed
* refactor client
* formatting
* update tests from pr comments and re-record
* re-record and generate after PR feedback
* update tests because of service deployment
* add filter after rebase
Co-authored-by: Ankit Arora <ankita@microsoft.com>
* [communication-common] Add options bag for getToken function, mark @hidden where applicable
* rename url to endpoint in CommunicationIdentityClient constructor
* adding core-https as a dep
* migrate to core-https
* address feedback
* address feedback
* fix failure
* address feedback
* ditch httpsClient
* move delay to be an internal function
* capitalize Unreleased
* revert delay changes
* [service-bus][test] extract key values into constants
CredScan is computing hashes to identify locations of possible sensitive data.
Changes unrelated to the key values can cause the hashes to change. This PR
extract key values into constants in a separate file so the scan results remain
stable.
* Keep just one testConstents.ts under test/public/
The service discovers relationships between healthcare entities and returns them as a list. This PR exposes this list after dereferencing the JSON pointers for healthcare entities.
Fixes https://github.com/Azure/azure-sdk-for-js/issues/14035
* Update live test templates to use matrix generation
* Update sdk live tests to use matrix generation, cloud config stages
* Fix live test matrix filter parity errors
* Remove matrix filters. Opt-in most tests to samples and min/max testing
* Fix post step template parameter in monitor live tests
* Filter dependency version for live tests that don't support it
* Only publish test results for browser and node tests
When we were instrumenting spans we wouldn't pay attention to whether we were currently recording or not, which could lead to us creating a bunch of empty/null spans and trying to add them as links to the span for our batches.
Rather than do that I just check (when we instrument) if the span we created is recording and if not don't add it.
Fixes#13049
The current token refreshing mechanism in core-http was wrong. The token was being refreshed before the "refresh time buffer" was reached. I've added tests to verify the behavior (if we change the source back, the tests do fail, as expected).
With this PR, here's what we will be doing:
1. If a token is not there or has expired, we ask for a new one (of course).
2. Before a token expires, in a time window, we try to retrieve the token through a refresh promise.
3. As we get new requests to retrieve that token, we re-use the same refresh promise.
4. If the refresh promise fails, next incoming request will re-run the refresh promise only after some specific time. (This is true again, I reverted my changes to this)
Please let me know how this looks! Feedback appreciated.
Reverted: ~**[Important]**
The update after Jeff's approval is to fix the behavior to match the original intention. Only within the refresh window, while the valid token is still returned, the refresh promise should try to refresh the token once every 30 milliseconds (configurable) until the token expires. Once the token expires, the process does a final attempt to update it, then it stops.~
Incidentally fixes this customer issue, in which the token was refreshed more times than expected:
Fixes#13369
* [template] Make README Logging section consistent
We might have introduced the inconsistency for some libraries while copying
content from other languages.
* Update other README files
Contents for messaging libraries (Event Hub/Service Bus) remain unchanges
because they are different in having additional information about `rhea`
logging.
* linking to logger
- Remove BuildType parameter as we can default it from package properties
- Stop passing BuildType and GroupId and instead defaul them from package properties
- Enable StrictMode to help identify potential errors
- Start passing sdktype and isnewsdk properties to devops script
- Sync latest changes with devops work item to fix a couple bugs
Co-authored-by: Wes Haggard <Wes.Haggard@microsoft.com>
Removing custom createSpan code in favor of core-tracing's createSpan functions. As part of this I also changed messageBatch.tryAdd() options related to tracing so it matched what OperationOptions.
Also, fix in core-tracing so you can pass in a custom SpanKind (we were previously overwriting it).
Fixes#13985
See the issue linked above for a RCA on the bug this fixes.
## Issue
When using the @azure/abort-controller package, attaching event listeners to an abortSignal that remove themselves after being invoked can prevent other listeners attached to the same signal from being invoked.
## Solution
With this update, when abort() is called, we create a copy of the listeners array that isn't mutated when removeListener() is called on the abortSignal. This ensures that listeners are invoked in the same order they were added.
This PR has the below changes related to #13449
- Remove `@hidden` tag where `@internal` is already used
- Replace `@hidden` with `@internal` for members not exported from index.ts
Fixes minor typos in both prose and some of the example code (I
validated that the checked in samples were still correct, we just had
no coverage for the code in the README.md)
Fixes#13995
Update appconfig to use core-tracing/createSpan, rather than starting it's own spans.
- Reduced Spanner<T> to a single method (trace)
- Testing simplified
- Prep for otel 0.16+ upgrade that's coming.
As part of prepping for the next release of OpenTelemetry we found some code patterns that were going to become a large maintenance burden for us, primarily around the parenting of spans. To make this easier I've removed as many duplicate implementation of createSpan and tried to centralize everything into core-tracing instead.
This won't completely remove changes needed for a newer version of OpenTelemetry but it'll eliminate one of the bigger bottlenecks.
Dominik
Deyaaeldeen Almahallawi
Mike Harder
Sarangan Rajamanickam
KarishmaGhiya
Harsha Nalluru
Jeff Fisher
Bert Ong
Ramya Rao
Jianping Chen
Daniel Rodríguez
Ziheng Zhou(MSFT)
Ben Broderick Phillips
Chidozie Ononiwu
Jeremy Meng
colawwj
Richard Park
Azure SDK Bot
praveenkuttappan
chradek
Matt Ellis