* [engsys] fix check-format failures
- keyvault-command doesn't have samples-dev directory
- result of of `rush format`. formatting changes that potentially caused by prettier upgrade
* form-recognizer api.md formatting change
* upgrade dev dependency `puppeteer` to `^19.2.2`
* update pnpm-lock.yaml
* Fix failing tests
by changing them to verify `error.name`. The error message from parsing an
incomplete JSON string has been improved in recent versions of chromium.
Unfortunately it doesn't match NodeJS version any more.
Currently that log looks unrelated to any nearby code. This PR moves it to a
better place where the `maxConcurrentCalls` options is set. The info logged
still remains the same.
The comments indicates that it is possible that we receive more messages than we ask for, and we want to return them. However, in current code we only resolve after max-wait-time-after-first message has passed once we have extra because of the length equality check, and during the wait time, more messages could still arrive.
This PR changes to remove immediately when we get what we ask for or more.
When the remote closes the sender with an error we currently just log the error logged as a warning and are not doing anything else. Since we won't receive any response, the send operation eventually times out, rejecting with `OperationTimeoutError`. As `OperationTimeoutError` is retryable, we would get the same time out error in each retry again, even though some sender errors are not retryable, for example, `MessageSizeExceeded` error in issue #23623.
This PR rejects the promise of request on sender_error events so that it fails with proper errors. These errors still go through the retry logic, but should be failing faster.
### Packages impacted by this PR
`@azure/core-amqp`
***NO_CI***
- string replace in package json: 12 => 14 for engines/node and for dependency @types/node
- eslint: update `json-engine-is-present` rule to 14.0.0 as LTS version
- identity: react to typing improvements for `readFile()`'s `options.encoding`
- trivial generated api.md file changes due to @types/node version bump
RuleManager's `listRules()` async paging operation was implemented manually. Using core-paging primitive instead greatly reduces the code.
Service Bus doesn't support getting the total number of rules, so we only know that results are exhausted when the service returns an empty array. However, currently `core-paging` api would force us to return a page of empty result and undefined `nextPageLink` to stop the enumeration:
* current `getPage()` calls service api to get up to `maxPageSize` of elements. Suppose this is the last batch of results from service.
* `getPage()` returns a page of `{ page: results, nextPageLink: pageLink + results.length }` because we don't know yet whether there are more results we will try to get more.
* next `getPage()` calls service api again, getting empty results back
* With current core-paging api, we can now use `{ page: results, nextPageLink: undefined }` to stop paging. However, it is a page with an empty array, which is undesirable.
To address this, this PR also updates core-paging to allow returning `undefined` from `PagedResult.getPage` and we stop yielding pages after receiving an undefined page.
### Packages impacted by this PR
`@azure/core-paging`
`@azure/service-bus`
### Issues associated with this PR
#22108
- receiver common: complete, defer, abandon, deadLetter
- normal receiver: renewMessageLock
- session receiver: renewSessionLock, setSessionState, getSessionState
- when sending a single message
### Packages impacted by this PR
`@azure/service-bus`
### Issues associated with this PR
https://github.com/Azure/azure-sdk-for-js/issues/11858
* Update comment to refer to the right JS file
Change made is with regard to update the comment to which Javascript file to be ran under the `javascript` parent folder.
* Remove TS file extension in the comment
* Update sdk/servicebus/service-bus/samples/v7/javascript/receiveMessagesLoop.js
Co-authored-by: Harsha Nalluru <sanallur@microsoft.com>
This is ported from .NET PR https://github.com/Azure/azure-sdk-for-net/pull/30963
The service hardcodes a max of 1 minute and 5 seconds when accepting a session.
This means the retry timeout the user specifies in the client is ignored if they
specify a value higher than this. We should specify the timeout property in the
link settings properties when opening a link for next available session to
support long polling.
to ensure packages can get the `delay()` refactoring.
Without this change our `js - core` nightly is failing. It would fail the min-max testing as well.
What's happening is that our nightly pipeline does something special: for example, rewriting our @azure/core-util package versions to be like "1.1.1-alpha.20220909.2" so we can publish nightly alpha package of this version to npmjs.org.
If our other packages depend on the same minimum version (^1.1.1) then we also update the version to be ">=1.1.1-alpha <1.1.1-alphb" then rush would be able to find this version in the repository and we are building and testing against the version to be published.
However, if the version doesn't match (^1.1.0 in this case), we would not modify the dep version, and rush would get v1.1.0 from npmjs instead thus failed the build.
Using "^1.1.1" is also more correct for end users, as v1.1.0 satisfies the sem version ^1.1.0 but doesn't work.
### Packages impacted by this PR
core-util
### Issues associated with this PR
#15930
### Describe the problem that is addressed by this PR
- Update "delay" in core-util to support abort message
- Unduplicate "delay" function in core-http and core-amqp
### 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?
- Choose the implementation with "options" parameters to keep the flexibility in case we want to add extra functionality in the future
### Are there test cases added in this PR? _(If not, why?)_
### Provide a list of related PRs _(if any)_
#15832
### 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)
Previously our `build:samples` script would modify samples to import from
source. However, newer sample workflow no longer does this, and the
`build:samples` script now just "echo Obsolete".
This PR removes tests that guard against committing unwanted sample changes.
- Bump core-util minor version
- Update CHANGELOG files
- Update packages that depends on the particular change in this version.
- Remove -beta.1 as we already GA @azure/core-util.
* new test
* fix sending large messages
* formatting and docs
* format
* changelog
* more docs
* Update sdk/servicebus/service-bus/CHANGELOG.md
Co-authored-by: Jeremy Meng <yumeng@microsoft.com>
* Update sdk/servicebus/service-bus/test/internal/sendBatch.spec.ts
* Apply suggestions from code review
* fix error message
Co-authored-by: Jeremy Meng <yumeng@microsoft.com>
- add public `identifier` property to senders, receivers, and their
corresponding options
- `ProcessErrorArgs` now has `identifier` indicating by
which client the error is raised.
We intended to call `peekBySequenceNumber()` when `PeekMessagesOptions.fromSequenceNumber`
property is specified. However, currently other falsy values would also fail
the condition. This resulting in `peek()` is called instead, leading to
unexpected behavior.
This PR changes the condition to check for `undefined`.
***NO_CI***
This is a follow-up to PR #21536 and PR #21537.
- upgrade typescript to 4.6.0 for communication packages
- upgrade typescript to 4.6 for test-utils and dev-tool
- upgrade typescript to 4.6
* [ServiceBus] Add a sample of authenticating with AzureNamedKeyCredential
- add sample
- add a new auth rule and related env variables in test-resources.json
- update sample.env to have the new env variables
- use SERVICEBUS_HOSTNAME because the service endpoint contains https:// at the beginning and should not be sent to service.
when the `ServiceBusMessage` has `timeToLive` property set.
The problem is that we are adding a number to a `Date` object, resulting in an
invalid date value for `absolute_expiry_time`. This PR corrects it by calling
`getTime()` on the `Date` object first before adding the ttl number.
A unit test is added and the sendMessages sample is updated to show how to set
`timeToLive`.
* [ServiceBus] Add `identifier` property to `ServiceBusClient`
It's main purpose is to help correlate client logs and errors. It can be
specified when creating instances of `ServiceBusClient` via optional
`ServiceBusClientOptions.identifier`. If not specified, a unique one will be
generated.
- add property and client option
- plumbing the identifier to the link for sender and receiver
* React to lib code change.
* Add client id to `com.microsoft:receiver-name` link property for receiving
* update CHANGELOG
* Add some unit tests
* Move to `core-tracing` GA version ^1.0.0
* Update tracing support
* React to tracing changes in v1.0.0
* Remove test that no longer needed as the method was removed
* Fix util unit tests
* Remove createServiceBusSpan, createProcessingSpan, and createAndEndProcessingSpan
* Update changelog
* Remove deprecated `TryAddOptions.parentSpan` property
* Bump minor version
* [ServiceBus] prepare for 2022 July release
- change to use public trimmed type definition files for GA release
- update changelog
* Update release date
We should stop when there's no more returned rules. I did this previously
probably to support continuationToken as we have to make the last request to
know that there are no more results, and we then set continuationToken to
undefined on this empty page. Now that the continuationToken is removed, we can
stop yielding empty page.
* set up sample for filters
* modeling topicSubscription sample similar to .cs versions
* creating topics, subscriptions, and deleting rules
* created subscriptions with name, filter, and action (optional)
* should have sample done, but cannot run on basic tier
* added comments
* format
* revision
* formatting
* revised expected output
* revised naming and comments
* added clarifying comments
* delete samples
* update samples/
* restore samples/v7
* checkout
Testing reveals that if we use max int as maxCount, and also use top then
service will return InternalServerError.
This PR workarounds around that by defaulting to 100 as maxPageSize.
This RP rewrites the assertion with excluded properties with assertion on
expected properties. as log of `deepEqualExcluding()` doesn't give enough
information on the difference when the assertion fails.
### Packages impacted by this PR
@Azure/service-bus
This existed in Track 1 and allowed users with only Listen claims to manage rules on the subscription that they had listen claims for. In Track 2, this can be done using the `ServiceBusAdministrationClient`, but Get Rules and List Rules require Manage claims.
This PR adds a rule manager that can add, delete, and retrieve rules for a specified subscription via AMQP link.
### Issues associated with this PR
#20890
in public-trimmed dts rollup, @beta APIs are removed. Because we only ship
public-trimmed version it prevents us from gathering feedback for @beta APIs.
This PR enable generation of beta-trimmed dts rollup.
Use beta-trimmed dts rollup for beta release
- eslint to ^8.0.0
- @types/eslint to ~8.4.0
- @typescript-eslint plugins to ~5.22.0
* Fix broken test because of class property node type changes. Improve test a bit
to also verifying error line and column numbers
* Disable @typescript-eslint/no-invalid-this
After upgrading this rule reports more false positives. The following comment on the
github issue suggests that it doesn't work for some callbacks because it is just
a simple rule that doesn't do type analysis.
https://github.com/typescript-eslint/typescript-eslint/issues/3620#issuecomment-876810901
* Fix linter issues after upgrading the plugins in eslint-plugin-azure-sdk. Also upgrade eslint version in the impacted packages
Add an optional `omitMessageBody` option in `PeekMessagesOptions` allowing omitting message body when peeking messages. By default, message body is not omitted.
The perf framework previously did not support true multi-core operation. This PR provides an implementation of multicore support based on a message-passing model.
Two new options are added to the perf framework as part of this PR:
* `--cpus`/`-c`: number specifying the number of cores (CPUs) to use. Defaults to 1, set to 0 to match the number of cores on the machine.
* `--use-worker-threads`: boolean, defaults to false. Pass this flag to use `worker_threads` instead of `child_process` for multithreading (see Multithreading implementations, below)
* [ServiceBus] add custom endpoint support
- Port changes from Event Hubs. Most of work was done in core-amqp. This PR just
needs to connect the client options with the underlying connection context.
* Fix linter error
* format and build
* Address CR feedback
* Remove @azure/core-asynciterator-polyfill usage
* Remove @azure/core-asynciterator-polyfill usage
* Remove from workspace too
* Remove from core artifacts list
* Make eslint happy
* Fix more eslint errors
Co-authored-by: Jeremy Meng <yumeng@microsoft.com>
The log shows that when the test failed, the wait time is 1999 ms, close but
less than the expected 2000 ms. I suspect it is related to precision.
This PR allows some tolerance when checking the delay.
* log more information to help diagnose test failure in issue #20963.
* Update sdk/servicebus/service-bus/test/internal/unit/receiverCommon.spec.ts
Co-authored-by: Deyaaeldeen Almahallawi <dealmaha@microsoft.com>
* clean up old scripts
* tests -> perfTest
* base, event, batch perf test classes
* program.ts
* incorrect comment
* postSetup and preCleanup
* ParsedPerfOptions<TOptions = Record<string, unknown>> and related updates
* remove ! from options
* MockReceiverTest
* import "@azure/abort-controller" at perf classes
* BatchReceiveTest
* remove !
* changelog
* receiveBatch test
* remove aborter
* docs
* BatchSendTest
* receiveMessages
* no need of timer
* - Adds `PerfTestBase` and `BatchPerfTest`.
* lint fixes
* checkpoitn
* checkpoint
* manage parallels in base class
* parallels in base class
* MockEventReceiverTest and the framework
* fix readme
* formatting
* unneeded changes
* EventPerfTest
* mock test
* subscribe test for service-bus
* lint error
* formatting
* simplify
* update desc
* checkpoint
* subscribe-test
* mock event receiver 2
* formatting
* Address Mike's feedback
* lint format
* remove min-max delay
* maxEventsPerSecond logic
* Apply suggestions from code review
* Make EventPerfTest.eventRaise() and errorRaised() sync instead of async
- Methods do not perform any async work, and sync methods add less overhead to perf framework
* Cache event arrays to increase MockEventHubConsumerClient throughput
* Add MockReceiverTest to test list
* Improve throughput of MockReceiverTest
- Now matches NoOpTest * AverageBatchSize
- Also update options to match .NET
* Jeremy's feedback
* Clear the duration timer if the test ended sooner
* Mike's feedbakc
* lint:fix
* minor feedback
Co-authored-by: Mike Harder <mharder@microsoft.com>
### Issues associated with this PR
Resolves#19234
### Describe the problem that is addressed by this PR
Upgrades puppeteer to the latest version
### 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?
I looked through the changelog for puppeteer and did not see any major changes between 10 and 13 that should impact us
We claim that we can take `any` type of property values for properties to be
modified but it's `applicationProperties` part of a Service Bus message that is
modified. That property has a type of `number | boolean | string | Date | null`
and is what the service supports.
This PR corrects the types for these options to align with
`applicationProperties`. Even though it shows as a breaking change, other
unsupported types (e.g., an object literal) would cause service errors so they
never worked.
* Move to depend on core v2 libraries.
* Previously WebResourceLike.body is of type any so we were able to assign an object to it, then relies on the internal logic in
`executeAtomXmlOperation()` to stringify it to XML before sending the request. Now that `PipelineRequest.body` is strongly typed, `executeAtomXmlOperation()` is
updated to optionally take the strongly typed request objects for PUT
operations.
* Add a compatibility layer to transform PipelineResponse to HttpResponse like by copying most relevant properties of `WebResourceLike` and add copy of `HttpResponse`
* Bump version
* Stop verifying AbortError error message. It turns out that we now have a different error message after switching to Fetch
http client for browser. Previously we were catching the one from xhrHttpClient
but now we get a DOMException from browser. As error message isn't part of
public Api surface, the verification of error message is removed.
When receiving messages in a stream using `receiver.subscribe()`,
Under certain situation when the underlying connection is closed, we don't respect user request to close the receiver, but keep retrying to recover.
The problem is that we check the connection status and throw an error if it is closed in
`_initAndAddCreditOperation`. We restart retry cycle because of the error in the
`retryForEver()` function with the same operation, trying to re-establish the connection, then throw the same error again.
User calling `close()` wouldn't help because the place we
check for suspended state then throw `AbortError` is after we check the
connection and throw error.
This PR adds the checking of whether user has suspended the receiver before checking of connection so we
could throw `AbortError` to end the retry cycles. The check after `preInitialize()` invocation is still needed
as user could suspend us in the `preInitialize()` handler.
I also fix another issue of not respecting 0 values in user specified retry options.
### Packages impacted by this PR
@azure/service-bus
### Issues associated with this PR
#20388
- Service Bus and Event Hubs live tests used to take much longer time to run but we have
improved significantly since then.
- AppConfig live tests usually finish under 30 minutes.
* [ServiceBus] add delay between infinite retry cycles
Errors that are not retryable will be re-thrown out of the normal retry() call.
However, we don't have any delay before restarting the retry cycle.
This PR adds a delay before continuing the infinite retry cycles.
* Add a test and update changelog
also fixed the issue where we don't use `maxRetryDelayInMs` in Fixed retry
mode.
* Address CR feedback
* Update sdk/servicebus/service-bus/CHANGELOG.md
Co-authored-by: Ramya Rao <ramya.rao.a@outlook.com>
* Revert max delay limit in Fixed retry mode
as the setting only applies to Exponential retry mode.
Co-authored-by: Ramya Rao <ramya.rao.a@outlook.com>
when subscribing to a valid topic but an invalid or disabled subscription. Issue https://github.com/Azure/azure-sdk-for-js/issues/18798
The problem is that in these cases, the service accepts our client's cbs claim negotiation, and the receiver link is
created. The [client receiver enters](14099039a8/sdk/servicebus/service-bus/src/core/streamingReceiver.ts (L539))
the `retryForeverFn` to call `_initAndAddCreditOperation()`, where the following
```ts
await this._messageHandlers().postInitialize();
this._receiverHelper.addCredit(this.maxConcurrentCalls);
```
will return successfully, despite that the fired-and-forgot `addCredit()` call would later leads to
`MessagingEntityDisabled` or `MessagingEntityNotFound` errors in the underlying link. Since there's no errors thrown in
our retry-forever loop, the `onErrors()` [callback](14099039a8/sdk/servicebus/service-bus/src/core/streamingReceiver.ts (L541))
is not invoked. It is one place where the user error handler is called.
Because of the error, the link is detatched. We have code to re-establish the link when errors happen, so we call
`_subscribeImpl()` where the `retryForeverFn()` is called again. This goes on in an endless loop.
We used to invoke user error handler and would not attempt to re-establish connections when errors are considered
non-retryable. In PR #11973 we removed the classification of errors that `subscribe()` used and instead continues to
retry infinitely. We also removed the code to invoke user error handler. This PR adds code to invoke the user error
handler in `_onAmqpError()` so users have a chance to stop the infinite loop.
There's another problem. When users call `close()` on the subscription in their error handler,
`this._receiverHelper.suspend()` is called to suspend the receiver. However, when re-connecting we call
`this._receiverHelper.resume()` again in `_subscribeImpl()`. This essentially reset the receiver to be active and we
will not abort the attempt to initialize connection
14099039a8/sdk/servicebus/service-bus/src/core/streamingReceiver.ts (L574-L579)
To fix it, this PR moves the `resume()` call out. It is supposed to only called to enable receiver before
subscribing. It should not be called when we try to re-connect.
* Update ref doc on the receiver subscribe error handler
* Apply suggestions from code review
Co-authored-by: Ramya Rao <ramya.rao.a@outlook.com>
* Bring back processError() call in _onSessionError() callback
* Clarify that we retry on all errors when streaming
and link to ref doc on service bus errors.
* Bring back comments for resume() call
Also fix linting issue. The linter insists "@" in ts-doc should be escaped.
The url still works after adding "\"
* Re-remove comments
Co-authored-by: Ramya Rao <ramya.rao.a@outlook.com>
NodeJS would issue warning if the number of disconnected listeners on an event
emitter exceeds 10. When many sessions on a connection are closed but the
removal of the listener hasn't caught up, we will see this warning because the
default limit of 10 in NodeJS is too low. The disconnected listeners DO get
removed eventually in our code.
We already do this for senders created in Service Bus. This PR increase the
limit to 1000 for senders and receivers created off
`ConnectionContextBase.connection` so that the limites apply to both Service Bus
and Event Hubs.
* EH and SB no longer need to set max listener limit.
For Issue https://github.com/Azure/azure-sdk-for-js/issues/12161
**Packages impacted by this PR:**
- `@azure-tests/perf-service-bus-track-1`
**Issues associated with this PR:**
- #18982
**Describe the problem that is addressed by this PR:**
Add a test for receiveBatch using the track 1 service bus SDK in line with what we already have for the track 2 SDK
**Provide a list of related PRs** _(if any)_
- #18811
**Checklists**
- [x] Added impacted package name to the issue description
**Packages impacted by this PR:**
@azure/event-grid, @azure/service-bus
**Describe the problem that is addressed by this PR:**
In order to conform to the OTel spec and allow for easier aggregations we
updated tracing policy to name the span `HTTP <method>` instead of `<path>`.
Unfortunately we missed a few tests, so this updates those tests to reflect the
core changes.
While editing these tests, I realized I never added CHANGELOG entries for the original
change. This PR addresses that as well.
**Provide a list of related PRs**_(if any)_
#19838Resolves#19887Resolves#19885
* base code
* 'Retry-After',
'0',
manual replacements
* setDefaultRetryAfterIntervalInNockFixture
* setDefaultRetryAfterIntervalInNockFixture
* changelog
* changelog
* docs
* docs
* 19501
* Update sdk/test-utils/recorder/test/node/utils.spec.ts
* Format
* Update recordings to have retry-after value of 0
and remove some 202 responses
Co-authored-by: Jeremy Meng <yumeng@microsoft.com>
* [ServiceBus][Test] Fix Min-Max test build failure
With `@types/long` min version of `4.0.0` we got compilation error
```
Namespace 'Long' has no exported member 'Long'.
```
version `4.0.1` fixes this.
* Update version for event hubs too
for non-existing queue.
When this test is running on China Cloud on a Mac build agent, it gets the
expected error except that it takes a little more than 3 seconds for the error
to come back.
This PR increases the timeout to 5 seconds.
* [ServiceBus][Test] fix unstable tests that verify message state
The test messages we create have `scheduledEnqueueTimeUtc` set. Most of the time
messages received from the service have "active" state, but occasionally have
"scheduled" state due to the set property, thus failing the assertion.
This PR updates the check to check for either "active" or "schedule". In
addition, a test is added for "active" state where the `scheduledEnqueueTimeUtc`
property is removed before sending the message.
Also shown in the failing pipeline that when the test failed, the message wasn't
removed because `receiver.completeMessage()` is not called. The lingering
message caused the next test to fail. While updating the tests I also moved the
cleanup step before assertions so the message should always be removed.
* Undo changes to pipeline
* Address CR feedback
* Disable linting rule
* Remove an unstable assertion on message state.
Resolves#17075
This PR updates the version of ws from v7 to v8
The breaking changes in the changelog do not affect the way we use it. See https://github.com/websockets/ws/releases/tag/8.0.0
Chose to go with `^8.2.0` to match the version being used by `@azure/web-pubsub`
As discussed in #17076, we no longer have the need for the `docs` script in each of our packages. This PR removes this script and the related dev dependency on typedoc
This PR makes the following updates regarding the `nyc` dependency
- Update to v15 from v14 across all packages
- Updates to `@azure/monitor-opentelemetry-exporter` as it failed to run the tests with the updated nyc.
- Update the test scripts to use the js files in the dist-esm folder like all other packages instead of using the ts-node plugin.
- Update one of the tests for `@azure/monitor-opentelemetry-exporter` to use the right path for package.json file now that the tests are being run from the dist-esm folder.
Random set of live tests were triggered from this PR to ensure that nyc works as expected.
The failure for data-tables is an unrelated service side issue
Resolves#19232
## What
- Patch service-bus and event-hubs' rollup config with custom plugins that are required for test runs
- Replace `assert` with `chai`
## Why
We tried to use the shared rollup config across packages but unfortunately service-bus event-hubs are and will likely remain a special case due to the various dependencies it pulls in. We identified a few fixable issues but there are some
that will not be easily resolved.
So, working with Will we decided a reasonable compromise is to use the shared config but patch the plugins so that they
match what they were before the recent changes.
In passing, I am also removing any imports of the `assert` module as that has been removed and the tests are failing. So
this should fix that as well.
* [ServiceBus] Add optional boolean `skipParsingBodyAsJson` option
to `ReceiveMessagesOptions`, `SubscribeOptions`, and
`ServiceBusSessionReceiverOptions`. This allows users to control whether the SDK
should skip parsing message body as Json object. By default the SDK will attempt
parsing message body as Json object.
While updating code, I also fixed sample unit test which is using out-dated
paths thus not finding any sample code files, and removed two `await` that are
redundant.
Resolves#18630
* Add optional `skipParsingBodyAsJson` boolean property
to `ServiceBusReceiverOptions` and remove those on `ReceiveMessagesOptions` and
`SubscribeOptions`
* Remove commented code that was trying to decode again
but the message body is already decoded, and _rawAmqpMessage is assigned in
`fromRheaMessage()`
* Remove double decoding
message.body has been decoded already above by `fromRheaMessage()` call.
* Update CHANGELOG and package version
* Add comments
* Update sdk/servicebus/service-bus/CHANGELOG.md
Co-authored-by: Deyaaeldeen Almahallawi <dealmaha@microsoft.com>
Co-authored-by: Deyaaeldeen Almahallawi <dealmaha@microsoft.com>
## What
- Fix incorrect logic when suppressing chai's circular dependency warnings
- Move to the common dev-tool configuration where possible
## Why
This is a longstanding issue that we have, where an incorrect logic was copy-pasted to other places. I figured while cleaning this up that any package I touch can just convert over to the shared dev-tool configuration. Where I was unable
to do that, I just fixed this bug to avoid too many changes in one PR.
Fixes#14292Resolves#17818Resolves#17816Resolves#17815Resolves#17814Resolves#17813Resolves#17810
It can be one of the three `ServiceBusMessageState` values: `"active"`, `"deferred"`, or `"scheduled"`.
Several tests are updated to verify the message state property.
* [ServiceBus] Enable linting
* Fixing most linting errors in tests
* Fix more linting errors in src
* Disable errors
- for namespace
- parameter of `any`
* make key const and value mutable
* Add `.catch()` block for promise
* address CR feedback
* format
* Delete test input of undefined ruleOptions for createRule() test
* Use different overloads of `crateRule()`
* Update to the new rule name
* in browser, the error caught doesn't have message property!
AssertionError: expecting valid error.message but error is [object CloseEvent]: expected undefined to be truthy
Related to #14581
In https://github.com/Azure/azure-sdk-for-js/pull/18463, we updated all samples to use GA of Identity v2
In https://github.com/Azure/azure-sdk-for-js/pull/18470, we updated devDependencies of Identity v2 beta to use Identity v2 GA
This PR removes the dependency overrides put in place for the reason (am guessing) that we wanted tests to use the beta v2 Identity, but not samples
Now that the samples are using v2, we no longer need the dependency overrides
Reported in #18033.
Basically did a bulk find+replace everywhere. Things _seem_ to be working OK, but wouldn't be surprised if there's something somewhere I've missed, or somewhere where I've replaced something I shouldn't.
I've split the rename of PerfStress -> Perf and runAsync -> run into two commits for ease of review :)
* ServiceBusAtomAPIVersion
* older API Version is broken
* tests
* rename
* changelog
* getRandomServiceVersion
* remove .only
* address Jeremy's feedback
* serviceVersion comments
* docs
* test with both the api versions
* Donot expose ServiceBusAtomAPIVersion
* test
* doc update
* Fix retry handling for Session Not Found errors
* Update sdk/cosmosdb/cosmos/test/internal/session.spec.ts
Co-authored-by: Zachary Foster <zfoster@users.noreply.github.com>
* Update CODEOWNERS for Application Insights (#17055)
* MaxMessageSizeInKilobytes api
* sample,test.env
* API Report
* add tests
* finish the tests
* remove console.log
* arm template
* put .only to test in CI with limited tests
* minor test update
* remove .only, add changelog
* Update sdk/servicebus/service-bus/src/util/constants.ts
Co-authored-by: chradek <51000525+chradek@users.noreply.github.com>
* wrap text - changelog
* maxMessageSizeInKilobytes: 256 by default for Standard namespaces
* Revert "maxMessageSizeInKilobytes: 256 by default for Standard namespaces"
This reverts commit 4f425634b6.
* exclude "maxMessageSizeInKilobytes"
* (Configurable only for Premium Tier Service Bus namespace.)
* Version 7.3.1-beta.1
* update version at more places
* lock file
* Update sdk/servicebus/service-bus/CHANGELOG.md
Co-authored-by: Adam Ling (MSFT) <adam_ling@outlook.com>
* lock file
* non optional in EntityProperties
* api report
Co-authored-by: Steve Faulkner <southpolesteve@gmail.com>
Co-authored-by: Zachary Foster <zfoster@users.noreply.github.com>
Co-authored-by: omziv <80668253+omziv@users.noreply.github.com>
Co-authored-by: chradek <51000525+chradek@users.noreply.github.com>
Co-authored-by: Adam Ling (MSFT) <adam_ling@outlook.com>
## What
- Update API Extractor to the latest version (currently 7.18.11)
- Regenerate all API reviews by building all the packages
## Why
This is something we keep bumping into. First, we needed to upgrade API Extractor to allow us to re-export directly from
`@opentelemetry/api`. Then, it looks like we needed this to upgrade TypeScript to 4.4.
We are way behind on this version, and it's time to upgrade.
## Callouts
How noisy is this?! Here's what's happening - somewhere around 7.9 I think API Extractor improved the way it detects name
collisions with predefined globals. Things like KeyType, Response, etc.
If there's a clash, the generated API markdown file will rename <Item> to <Item_2> to make the name collision explicit.
Talking to folks on the team, and the poor souls that will be doing API Review approvals, we agreed that doing the upgrade
in one fell swoop is the way to go.
Resolves#9410
* Add PoliCheck tool to aggregate report pipeline
* Exclude recordings from policheck run
* Use upper case for folder exclusion
* Fix up policheck issues
* Move CredScan into the Compliance stage
* Fixup policheck issues
Resolves#17089
`@azure/abort-controller` doesn't use `delay` in any tests, so easy removal.
`@azure/service-bus` used `delay` for perf tests, but only as a promisified setTimeout. Removed dependency and replaced with a simple delay function.
* Remove leftover recordings whose tests had been deleted
* Move test secrets into file so we can suppress the file, instead of suppressing using the unstable hashes
* Update suppression list
* move to the new structure
* minor edits
* sample.env and readmes
* more changes
* track 2 service-bus looks fine
* track 1 also seems fine
* more fixes
* formatting
* Update sdk/eventhub/perf-tests/event-hubs-track-1/README.md
Co-authored-by: Daniel Rodríguez <sadasant@users.noreply.github.com>
* Update sdk/eventhub/perf-tests/event-hubs-track-1/README.md
* Apply suggestions from code review
* lock file
* lock file from master
* lock file
* all minor feedback
* more formatting
* remove prebuild
* more care for readmes
Co-authored-by: Daniel Rodríguez <sadasant@users.noreply.github.com>
## 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
* [Identity] Incrementing the package version
* setting samples to the last released version of Identity
* upgraded non-samples to 2.0.0-beta.6
* found a fix for the CI issue
* Re-organize eh stress files for stress test layout
* Add service bus stress test helm chart
* First pass generating stress job for each scenario
* Deep copy global template scope in stress test range loop
* Updates and deployment files for service bus stress
* Use base arm template
* fix helm template and docker build
* Final fixes to get service bus stress tests working
* [stress test] Update to use built-in scenario range addon
* [stress test] Minor fixes
* Update stress test program locations
* Run prettier over service bus stress test files
This PR adds missing changelog entries for the times we
- updated tracing dependencies to use the GA version of OpenTelemetry
- updated to target ES2017
## What
- Remove `setTracer`
- Remove `NoOpTracer` and `NoOpSpan`
- Use Otel's APIs where possible (like when creating a no-op)
- Respect AZURE_TRACING_DISABLED environment variable
- Include test support for tracing utilizing OTel's trace API
- Avoid injecting invalid `tracerparent` header fields
## Why
- `setTracer` was added before OTel had their own implementation of a global tracer provider. For consistency with other libraries we should use the global tracer that was registered. It also leaves us out of the business of maintaining caches, global tracers, and other annoying things.
- These are no longer needed, since OTel has a recommended way to wrap a span in a NoOp. And, if no tracer provider was registered, a non-recording tracer (NoOp) will be created. All managed by OTel
- Finally, AZURE_TRACING_DISABLED is one of the env vars our guidelines say we should support
Resolves#16088Resolves#15730Resolves#10205
## What
- Move `TestTracer`, `TestSpan`, and `SpanGraph` from @azure/core-tracing to @azure/test-utils
## Why
1. Having a folder called src/**test**/ does not play nicely with defaults generated by tools such as Yarn (specifically Yarn autoclean)
2. These are test support interfaces, and shouldn't be part of our public API anyway - now that we have @azure/test-utils it's the more appropriate location for them
Resolves#16265Resolves#16201
Related #13367
We have an intermittent issue where we close a session and it releases, but there is a delay (Documented as part of this issue here: [link](https://github.com/Azure/azure-sdk-for-js/issues/14441). We've seen it in our normal live tests (not every time, but often enough to be noted).
I've done two things to make this "better":
- Mitigated the issue so we can still get a decent test signal by making the tests no longer use the same session ID. They didn't actually need to send or receive messages for the test itself (it's just validating that we're adding the right amount of credits) so I simplified the tests.
- Put in some wrapper code to make it simpler to reproduce the issue in the future. It will basically run these session based tests 1000x, which still doesn't _always_ reproduce the issue but can.
As a bonus, there was a `peekMessages()` test that expected that a message that has been sent will immediately be available, which isn't always true (there can still be a delay between "message accepted" and "message receivable"). I've fixed this test by doing a `receiveMessages()` first (which will wait until messages are available), abandoning the message and then doing a peek, which should work more reliably.
Fixes https://github.com/Azure/azure-sdk-for-js/issues/15666
It also turns out the samples depended on the `next` tag for service-bus, which is no longer published on NPM, so this update fixes that issue by depending on the `latest` tag.
* displayed links as a list rather than a single line
* appconfiguration\Readme: displayed links as a list rather than a single line
* confidential-ledger-rest/README.md: display links as list
* container-registry/README.md: display links as list
* cosmos/README.md: display links as list
* iot-device-update/README.md: display links as list
* eventgrid/README.md: display links as list
* event-hubs/README.md: display links as list
* eventhubs-checkpointstore-blob/README.md: display links as list
* formrecognizer/README.md: display links as list
* identity/README.md: display links as list
* iot-modelsrepository/README.md: display links as list
* keyvault-admin/README.md: display links as list
* keyvault-certificates/README.md: display links as list
* keyvault-keys/README.md: display links as list
* keyvault-secrets/README.md: display links as list
* ai-metrics-advisor/README.md: display links as list
* mixedreality-authentication/README.md: display links as list
* monitor-query/README.md: display links as list
* purview-catalog-rest/README.md: display links as list
* purview-scanning-rest/README.md: display links as list
* quantum-jobs/README.md: display links as list
* search-documents/README.md: display links as list
* schema-registry/README.md: display links as list
* schema-registry-avro/README.md: display links as list
* service-bus/README.md: display links as list
* storage/storage-blob/README.md: display links as list
* storage-blob-changefeed/README.md: display links as list
* storage-file-datalake/README.md: display links as list
* storage-file-share/README.md: display links as list
* storage-queue/README.md: display links as list
* data-tables/README.md: display links as list
* ai-text-analytics/README.md: display links as list
* video-analyzer-edge/README.md: display links as list
* web-pubsub/README.md: display links as list
* web-pubsub-express/README.md: display links as list
* core-lro/README.md: display links as list
* changed from the word master to main
* changed the word master to main
* another update to the final reandme to change the word master to main
* Update README.md
fixed a type in the link
* Update sdk/anomalydetector/ai-anomaly-detector/README.md
Co-authored-by: Deyaaeldeen Almahallawi <dealmaha@microsoft.com>
Co-authored-by: Deyaaeldeen Almahallawi <dealmaha@microsoft.com>
Fixing an issue where we could lose messages or provoke an alarming message from rhea (`Received transfer when credit was 0`)
The message loss issue is related to how we trigger 'drain' using 'addCredit(1)'. Our 'receiver.drain; receiver.addCredit(1)' pattern actually does add a credit, which shows up in the flow frame that gets sent for our drain. This has led to occasionally receiving more messages than we intended.
The second part of this was that we were masking this error because we had code that specifically threw out messages if more arrived than were requested. If the message was being auto-renewed it's possible for the message to appear to be missing, and if we were in receiveAndDelete the message is effectively lost at that point. That code is now removed (we defer to just allowing the extrra message, should a bug arise that causes that) and we log an error indicating it did happen.
The rhea error message appeared to be triggered by our accidentally allowing multiple overlapping 'drain's to occur (finalAction did not check to see if we were _already_ draining and would allow it to happen multiple times). Removing the concurrent drains fixed this issue but I didn't fully investigate why.
Fixes#15606, #15115
## What
- Update core-http to 2.0.0
- Update core-lro to 2.0.0
- Update packages to use latest version
## Why
This will support our last breaking change for core-tracing, and allow everyone to be on the same minimum version. This will also allow us to target ES2017 across the board.
Today we cache any opened links in the connectionContext. These links should be removed when the link itself is closed but, due to a mismatch in the values, we weren't.
I've fixed this by just making an abstract method in LinkEntity (the base for all the link types) and just having each link properly remove itself from the cache.
Fixes#15890
Making changes to simplify a flaky test (and hopefully make it more reliable).
The main issue with the 'handle interrupted detach' method was that it relied on too many moving parts to work reliably. We could just eternally loop like we'd expect customers to do, but in the end we have a very simple test we're trying to perform - we want to receive, and while we're in the process of draining, cause a detach and have it early exit and reject/resolve immediately rather than waiting for the timeout.
I reworked the test to make that simpler by just removing the unneeded connection.idle() and just calling directly into the onDetached method. Because it happens prior to rhea even seeing that we're draining we should reliably win that race each time.
There were a couple of other things changed for this PR as well:
- The max time per test was lowered accidentally. Bringing it back what's been used as the standard time in other libraries
- Fixed a spot in receiveMessages() where, if the link had been closed, we'd falsly return an empty array instead of throwing an exception indicating the link closed. This didn't appear to be related to the bug but it's incorrect and can hide bugs so I'd rather just throw the error than eat the condition and return an empty array. It's rare, but when it does happen the empty array response isn't right either - we're probably in the middle of a connection reset/change event.
Fixes#13461
## What
- Bump @opentelemetry/api to 0.20.0 in @azure/core-tracing
- Move all packages that are on core-http to the next core-tracing version
- Remove version collision check from the tracer cache
## Why
This is part of our effort to move everyone to OTel 0.20.0 - but we have to stage it due to a transitive dependency and a
breaking change in OTel. This PR updates core-tracing to use the latest OTel, fixes any breaking changes, and moves
packages that we can move to the latest version of core-tracing.
Once core-rest-pipeline 1.1.0 is GA'd we'll be able to move the rest of the packages over to the latest core-tracing as well.
Removing the version collision came out of an offline discussion after these changes were reviewed - since it's a common
source of pain and hasn't added much benefit (tracer conflicts incompatibility was never a problem) we decided to remove
that logic and always grab a unique symbol per OT compatibility.
## Callouts
The packages that are already on core-v2 will _not_ be upgraded at this time - we'll coordinate that with the GA of core-rest-pipeline 1.1.0
As we are ending the support for IE 11, this PR remove doc and test logic that
handle IE.
- Remove commented polyfill from karma configs
- Remove IE compatibility section from Stroage README files
- Remove IE specific logic from storage tests.
- Remove Storage TODO comments for IE.
* format
* run format on core-client-rest
Updating doc comment for autoComplete, indicating that it will abandon() if an error is thrown.
The prior text made it sound like it would call complete() no matter what happened, which was confusing.
Fixes#15519
* [service-bus] pass abortSignal to link initialization and awaitableSender
* [service-bus] add changelog entry
* [core-amqp] remove AsyncLock!
* [service-bus] fix test after the great merge
* npm run format
* fix abort on send after great merge
This PR fixes#13500.
`rhea` 2.0.1 contains the fix to this specific error. We currently use `rhea` 1.x, so there's additional work in this PR to workaround the single breaking change in `rhea`, and the breaking changes in `rhea-promise`.
### rhea breaking change
`rhea` contains 1 breaking change between versions 1.x and 2.x: timestamp types are now deserialized as Date objects instead of numbers. Unfortunately since this changes the way users' data might be deserialized in their service bus messages or event hubs events, we have to convert Date objects back to numbers in our client libraries until we do a major version bump. (Shorter term we can look at using rhea's default behavior behind a flag.)
### rhea-promise breaking changes
Some of the `rhea-promise` APIs that accepted multiple optional positional arguments have been updated to take a single options bag parameter at the end of their method parameter list.
AwaitableSender was also updated so that a timeout is no provided at instantiation. Instead, it must be provided per each `send()` call.
### core-amqp v3
Since core-amqp is being updated to depend on rhea 2.x, core-amqp dependencies will also pull in rhea 2.x transitively.
To ensure that existing versions of event hubs and service bus don't break by deserializing timestamps as Date objects, core-amqp is updated to a new major version: v3.
Once #15349 is merged, we can also remove `AsyncLock` completely, so I'd like to merge that PR in before releasing the changes in this PR.
Updating samples to fix a few issues:
- Show the right way to restart your receiver when using sessions (which
don't do automatic retries like non-sessions).
- Some of the samples printed almost too little console output to indicate what
they were doing or didn't demonstrate the right techniques (asking for multiple
messages at a time, etc..). Those have been updated as well.
Fixes#14531
getMaxMessages had an edge case where the link being closed just after open would cause us to access a link that was undefined and throw a non-retryable exception.
This PR fixes that by checking that the link is defined, and throwing a retryable exception if it is not.
Fixes#15398
Finishing work to enable AMQP body type encoding
- We completely missed the schedule messages code path. Added, with tests.
- Consolidated the two files of AMQP messaging tests into the `public` branch so we also get min/max testing. Removed all references to non-published interfaces.
Re-enabling the AMQP body type encoding feature. We disabled this temporarily when we released 7.1.0 and are now re-enabling this in time for our new preview: 7.2.0-beta.1
Jeremy Meng
Azure SDK Bot
kazrael2119
Jeff Fisher
Jeremy Meng
Charles Mwaniki
Harsha Nalluru
Minh-Anh Phan
Timo van Veenendaal
Daniel Getu
Ben Zhang
hamsa-s
praveenkuttappan
colawwj
praveenkuttappan
Matthew Podwysocki
Will Temple
Maor Leger
Wenjie Yu（MSFT）
Deyaaeldeen Almahallawi
Jonathan Cárdenas
Ramya Rao
Ben Broderick Phillips
Timo van Veenendaal
Hiroshi Yoshioka
Chidozie Ononiwu (His Righteousness)
chradek
Daniel Rodríguez
Richard Park
bashiMoha
Chidozie Ononiwu
KarishmaGhiya
Jose Manuel Heredia Hidalgo