* Fix @azure/azure-sdk/ts-package-json-keywords failure
* Fix tsdoc/syntax errors for @param tag
* Fix tsdoc/syntax error for usage of @ for non tag
* Run lint:fix
* Update lintreport name
I was trying to remove some of the unused dependencies in our packages and this invariably will change the lock file. Found that `@types/node` v12 had a patch update in the past 24 hours that caused much noise to my updates. So, creating this PR with just `rush update --full` so that my future PRs can have less noise
Please note that the automated weekly PR that does this was already run yesterday and merged
* update rush.json
* lock file
* package.json, rollup and tsconfig
* src file
* test
* add recorder.stop call
* set http
* set protocol to http
* core-rest-pipeline draft
* storage test
* keep only the storage test
* lock file
* update package.json
* recorder-new
* lock file
* undefined to null
* remove target es5
* add a guide with starter steps
* testing-recorder-new
* lock file
* types - recorder-new
* import urlBuilder from core-http
* disclaimer in the guide
* comment out the test in recorder-new
* testing recorder-new setup and test
* rest-pipeline 1.1.0
* lock file
* "versionPolicyName": "test" and sdkType
* karma.conf
* fix package.json
* update test to take sas url
* omit readme checks for testing-recorder-new, recorder-new
* lock file from master
* lock file and readmes
* remove TEST_MODE variable
* update readme with temp-location
* resources update
* skip runnign in ci
* update package.json
* remove console.logs and fix queue name
* fix browser mappings
* index.browser.ts and console.logs
* remove .olg from clean command
* test file with logs
* update readme
* update readme to reflect additional environment variables that must be set
* login steps
* lock file
* test file
* Copying the recordings saved in the container
* remove console logs
* "@azure/data-tables": "^12.1.2"
* dependencies
* rename test file
* core-v2 recorder first draft
* core-v2 node test works
* karma-conf fix
* uri -> url
* update tests
* refactor core-v1 and core-v2 recorder clients
* refactor common code between core-v1 core-v2 and node and browser
* renames and underscore removals
* typings -> types
* address feedback
* RecordingStateManager
* lock file
* lock file
* lock file from master
* lock file
* recorder-new package test skipped
* delete commented test file
* Update sdk/test-utils/testing-recorder-new/README.md
* empty test file
* lock file
* add link descriptions
* Daniel's feedback
* Update sdk/test-utils/recorder-new/README.md
Co-authored-by: Scott Beddall <45376673+scbedd@users.noreply.github.com>
* Scott's feedback
* Addressing Will's feedback
* Add tslib
* RecordingState
* lock file
* currentState
* lock file
* docker cp
* remove lib from tsconfig
* more feedback
* utils file and base tests
* update error message
* initial set of tests
* Add copyright headers
* No need of the if checks
* both Test_Modes
* Append ${testMode} mode:
* karma conf and tests
* Daniel's new found love - npm run clean move from prebuild to build
* Added many many comments for Daniel 🐱👤
* lock file
* package renames
Co-authored-by: scbedd <45376673+scbedd@users.noreply.github.com>
* Adding a note in the readme to release publicly
* rename `@azure/test-utils-recorder` to `@azure-tools/test-recorder`
* lock file
* delete recorder new file
Fixes#14063
This update improves the event instrumentation logic so that spans are only created if tracing is enabled. This fixes the issue where adding events to an EventDataBatch led to empty spans being created when tracing was not enabled.
The `instrumentEventData` function is similar to the `instrumentMessage` function in service bus. The main difference is that in event hubs we need to check if the event being instrumented is an AmqpAnnotatedMessage or an EventData since properties are stored in a different field (properties vs applicationProperties) depending which is used.
In service bus, the ServiceBusMessage uses applicationProperties, so no distinction versus AmqpAnnotatedMessage is needed there.
/cc @maorleger
## What
- If a span is not recording, return early and avoid doing any more work
- Update some missed test setup
## Why
When tracing is either not configured or the newly created span is not sampled this information would get dropped
from both telemetry and request headers (since the serialized span context will not be valid).
We can return early in that case. It'll have several benefits:
1. Less instances of the Span#context / Span#spanContext rename issues (since we won't get there)
2. We can avoid some processing overhead, although for a non recording span it is probably (but not surely) very lightweight anyway.
## Callouts
Being able to avoid creating the span (and the URIBuilder overhead) is currently not possible for multiple reasons:
1. The OTel API does not provide a way to check whether tracing is globally configured https://github.com/open-telemetry/opentelemetry-js-api/issues/118 nor will that be supported in the future
2. Checking the current parent span is not an option either - due to sampling logic it's possible that the parent span is not recording but this span will be
So this is about as good as we can get for now.
Skipping CHANGELOG because the overall behavior should not change from a client's perspective.
Resolves#16580
## What
- Removes spanOptions from OperationTracingOptions
- Prepares client package for compatibility with both existing and future core-tracing code by adding runtime casts / checks where spanOptions are concerned
- Adds `az.namespace` as an attribute on the current context, ensuring that it is available for tracing policies
- Adds spanOptions as a parameter to `createSpan` allowing customization of a newly created span
- Prepare tracingPolicies for backwards and forwards compatibility at runtime by using spanOptions as well as spanContext to determine the value of az.namespace to set on spans.
**Does NOT upgrade client libraries yet and their API will NOT change until we upgrade**
## Why
spanContext originally existed to be able to shepherd attributes around in order to add them to any child spans. Specifically, we need to add the az.namespace to the outgoing request span. Now that `tracingContext` is available as both a bag of values as well as a container for parenting info, we no longer need spanOptions.
Actually, spanOptions grew to add enums and other elements that caused us pain in the past. See #15285 as an example.
Finally, providing spanOptions as a publicly available option bag means that we are providing ways for consumers to customize our own spans. We don't need that, as we own the spans we create.
But what we still need to provide is a way for our own libraries to customize the spans they produce. By moving spanOptions off of OperationTracingOptions and into a separate parameter in createSpan we can support this.
## Callouts
I tested compatibility here in multiple ways:
1. I changed core-tracing's version to preview.13 so that all libraries will run tests against the new package
2. I then changed it _back_ to 14, so that all libraries will run tests against the old pacakge
3. I packed preview.13 with new bits and installed published packages for a few libraries and manually tested a few scenarios
Resolves#15285Resolves#16726
In this PR I’m fixing a broken link. It pointed to a feature branch, and it correctly routed to it while we were developing the feature, but after merging an deleting that branch, the link is now broken! (reasonably so). Let’s clean it up!
Thank you, @jeremymeng for letting me know about this.
* Stress test deployment script resiliency fixes
* Use PSModule-Helpers to install powershell-yaml
Co-authored-by: Ben Broderick Phillips <bebroder@microsoft.com>
As requested by https://github.com/Azure/azure-sdk-for-js/pull/7060#issuecomment-887480513, this PR adds a sample for converting an IoT Hub connection string to an Event Hubs-compatible connection string using web sockets.
The main difference is that websocket options need to be specified, and the port used to connect changed from 5671 to 443.
/cc @wiegvlieg - let me know if this helps or if you have more questions about how this sample works.
* [Cosmos] remove deprecated @types/fast-json-stable-stringify dependency
as recommended by
```
WARN deprecated @types/fast-json-stable-stringify@2.1.0: This is a stub types definition. fast-json-stable-stringify provides its own type definitions, so you do not need this installed.
```
* Upgrade "fast-json-stable-stringify" to "^2.1.0",
* Run `rush update --recheck`
Harsha Nalluru
Azure SDK Bot
Deyaaeldeen Almahallawi
praveenkuttappan
Jeremy Meng
Ramya Rao
Jose Manuel Heredia Hidalgo
Daniel Rodríguez
Maor Leger
Zachary Foster
govardhan
chradek
colawwj
luc
Steve Faulkner
Suyash Sonawane
Qiaoqiao Zhang