Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Track One] Tests for closing the Event Hub client are unstable during nightly runs #7435

Closed
jsquire opened this issue Aug 30, 2019 · 1 comment
Assignees
Labels
bug This issue requires a change to an existing behavior in the product in order to be resolved. Client This issue points to a problem in the data-plane of the library. Event Hubs Service Attention Workflow: This issue is responsible by Azure service team.

Comments

@jsquire
Copy link
Member

jsquire commented Aug 30, 2019

Summary

A recent change introduced new tests to verify the behavior that when an EventHubClient is closed, any senders and receivers that were created by that client are also marked as closed. These tests have proven to be non-deterministic during nightly test runs, failing intermittently but frequently.

An example failure can be found in the nightly results from August 30. The failure looks like:

image

Scope of Work

  • Analyze the tests to understand the point of non-determinism and decide on an approach to stabilize for nightly runs.

  • Refactor the tests as needed to ensure that the results are deterministic and consistently pass.

Out of Scope

  • Changes or refactoring in other areas.

Success Criteria

  • The tests ClosingEventHubClientClosesSenderEntities and ClosingEventHubClientClosesReceiverEntities have been refactored or removed and no longer causes intermittent, but frequent, failures during nightly runs.

  • The changes did not cause regressions elsewhere; nightly test runs pass consistently and reliably with deterministic results.

@jsquire jsquire added Event Hubs Client This issue points to a problem in the data-plane of the library. labels Aug 30, 2019
@jsquire jsquire added the Service Attention Workflow: This issue is responsible by Azure service team. label Aug 30, 2019
jsquire added a commit to jsquire/azure-sdk-for-net that referenced this issue Aug 30, 2019
- Allowing slower backoff and higher jitter to account for the management plane
  behavior under load.  The management plane appears to have difficulty recovering
  after the first problem is encountered.  The hope is that giving it more time to
  recover and lowering the concurrent calls by randomzing retry times will help.

- Marking two tests in the track one library to be skipped, as they've been
  consistently unstable during nightly runs.  (tracking under Azure#7435)
jsquire added a commit that referenced this issue Aug 30, 2019
- Allowing slower backoff and higher jitter to account for the management plane
  behavior under load.  The management plane appears to have difficulty recovering
  after the first problem is encountered.  The hope is that giving it more time to
  recover and lowering the concurrent calls by randomzing retry times will help.

- Marking two tests in the track one library to be skipped, as they've been
  consistently unstable during nightly runs.  (tracking under #7435)
@JamesBirdsall JamesBirdsall added the bug This issue requires a change to an existing behavior in the product in order to be resolved. label Dec 11, 2019
@serkantkaraca
Copy link
Member

This is fixed now.

@github-actions github-actions bot locked and limited conversation to collaborators Mar 29, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug This issue requires a change to an existing behavior in the product in order to be resolved. Client This issue points to a problem in the data-plane of the library. Event Hubs Service Attention Workflow: This issue is responsible by Azure service team.
Projects
None yet
Development

No branches or pull requests

3 participants