[release/8.0] Fix cancellation unregistration in DataflowBlock.OutputAvailableAsync by stephentoub · Pull Request #102376 · dotnet/runtime

stephentoub · 2024-05-17T12:36:14Z

OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak.

The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

Backport of #99632

Customer Impact

Unbounded memory growth if a long-lived CancellationToken is used with OutputAvailableAsync; each call would end up rooting a small object into the token.

Testing

Normal CI testing, plus local stress testing to show that the leak no longer exists.

Risk

Low

…dotnet#99632) OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

dotnet-policy-service · 2024-05-17T12:36:47Z

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

ericstj · 2024-05-22T19:20:15Z

Approved in mail.

ericstj · 2024-05-22T19:20:39Z

Needs package authoring.

ericstj

LGTM

stephentoub · 2024-05-29T01:41:01Z

Thanks for taking care of the package authoring, @ericstj.

stephentoub · 2024-05-17T12:36:14Z

OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak.

The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

Backport of #99632

Customer Impact

Unbounded memory growth if a long-lived CancellationToken is used with OutputAvailableAsync; each call would end up rooting a small object into the token.

Testing

Normal CI testing, plus local stress testing to show that the leak no longer exists.

Risk

Low

…dotnet#99632) OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

dotnet-policy-service · 2024-05-17T12:36:47Z

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

ericstj · 2024-05-22T19:20:15Z

Approved in mail.

ericstj · 2024-05-22T19:20:39Z

Needs package authoring.

ericstj

LGTM

stephentoub · 2024-05-29T01:41:01Z

Thanks for taking care of the package authoring, @ericstj.

stephentoub · 2024-05-17T12:36:14Z

OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak.

The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

Backport of #99632

Customer Impact

Unbounded memory growth if a long-lived CancellationToken is used with OutputAvailableAsync; each call would end up rooting a small object into the token.

Testing

Normal CI testing, plus local stress testing to show that the leak no longer exists.

Risk

Low

…dotnet#99632) OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

dotnet-policy-service · 2024-05-17T12:36:47Z

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

ericstj · 2024-05-22T19:20:15Z

Approved in mail.

ericstj · 2024-05-22T19:20:39Z

Needs package authoring.

ericstj

LGTM

stephentoub · 2024-05-29T01:41:01Z

Thanks for taking care of the package authoring, @ericstj.

stephentoub · 2024-05-17T12:36:14Z

OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak.

The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

Backport of #99632

Customer Impact

Unbounded memory growth if a long-lived CancellationToken is used with OutputAvailableAsync; each call would end up rooting a small object into the token.

Testing

Normal CI testing, plus local stress testing to show that the leak no longer exists.

Risk

Low

…dotnet#99632) OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

dotnet-policy-service · 2024-05-17T12:36:47Z

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

ericstj · 2024-05-22T19:20:15Z

Approved in mail.

ericstj · 2024-05-22T19:20:39Z

Needs package authoring.

ericstj

LGTM

stephentoub · 2024-05-29T01:41:01Z

Thanks for taking care of the package authoring, @ericstj.

stephentoub · 2024-05-17T12:36:14Z

OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak.

The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

Backport of #99632

Customer Impact

Unbounded memory growth if a long-lived CancellationToken is used with OutputAvailableAsync; each call would end up rooting a small object into the token.

Testing

Normal CI testing, plus local stress testing to show that the leak no longer exists.

Risk

Low

…dotnet#99632) OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

dotnet-policy-service · 2024-05-17T12:36:47Z

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

ericstj · 2024-05-22T19:20:15Z

Approved in mail.

ericstj · 2024-05-22T19:20:39Z

Needs package authoring.

ericstj

LGTM

stephentoub · 2024-05-29T01:41:01Z

Thanks for taking care of the package authoring, @ericstj.

stephentoub · 2024-05-17T12:36:14Z

OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak.

The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

Backport of #99632

Customer Impact

Unbounded memory growth if a long-lived CancellationToken is used with OutputAvailableAsync; each call would end up rooting a small object into the token.

Testing

Normal CI testing, plus local stress testing to show that the leak no longer exists.

Risk

Low

…dotnet#99632) OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

dotnet-policy-service · 2024-05-17T12:36:47Z

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

ericstj · 2024-05-22T19:20:15Z

Approved in mail.

ericstj · 2024-05-22T19:20:39Z

Needs package authoring.

ericstj

LGTM

stephentoub · 2024-05-29T01:41:01Z

Thanks for taking care of the package authoring, @ericstj.

stephentoub · 2024-05-17T12:36:14Z

OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak.

The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

Backport of #99632

Customer Impact

Unbounded memory growth if a long-lived CancellationToken is used with OutputAvailableAsync; each call would end up rooting a small object into the token.

Testing

Normal CI testing, plus local stress testing to show that the leak no longer exists.

Risk

Low

…dotnet#99632) OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

dotnet-policy-service · 2024-05-17T12:36:47Z

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

ericstj · 2024-05-22T19:20:15Z

Approved in mail.

ericstj · 2024-05-22T19:20:39Z

Needs package authoring.

ericstj

LGTM

stephentoub · 2024-05-29T01:41:01Z

Thanks for taking care of the package authoring, @ericstj.

stephentoub · 2024-05-17T12:36:14Z

OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak.

The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

Backport of #99632

Customer Impact

Unbounded memory growth if a long-lived CancellationToken is used with OutputAvailableAsync; each call would end up rooting a small object into the token.

Testing

Normal CI testing, plus local stress testing to show that the leak no longer exists.

Risk

Low

…dotnet#99632) OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

dotnet-policy-service · 2024-05-17T12:36:47Z

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

ericstj · 2024-05-22T19:20:15Z

Approved in mail.

ericstj · 2024-05-22T19:20:39Z

Needs package authoring.

ericstj

LGTM

stephentoub · 2024-05-29T01:41:01Z

Thanks for taking care of the package authoring, @ericstj.

stephentoub added the Servicing-consider Issue for next servicing release review label May 17, 2024

stephentoub added this to the 8.0.x milestone May 17, 2024

ghost added the area-System.Threading label May 17, 2024

dotnet-policy-serviceBot assigned stephentoub May 17, 2024

build-analysisBot mentioned this pull request May 17, 2024
[8.0] Various WASM hybrid globalization tests failing in many languages #102348
Closed

ericstj added Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels May 22, 2024

Enable DataFlow package in servicing
dfbec3c

ericstj approved these changes May 22, 2024
View reviewed changes

stephentoub merged commit 48a9496 into dotnet:release/8.0-stagingMay 29, 2024

stephentoub deleted the backport99632 branch May 29, 2024 01:41

github-actionsBot locked and limited conversation to collaborators Jun 28, 2024

stephentoub added the Servicing-consider Issue for next servicing release review label May 17, 2024

stephentoub added this to the 8.0.x milestone May 17, 2024

ghost added the area-System.Threading label May 17, 2024

dotnet-policy-serviceBot assigned stephentoub May 17, 2024

build-analysisBot mentioned this pull request May 17, 2024
[8.0] Various WASM hybrid globalization tests failing in many languages #102348
Closed

ericstj added Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels May 22, 2024

Enable DataFlow package in servicing
dfbec3c

ericstj approved these changes May 22, 2024
View reviewed changes

stephentoub merged commit 48a9496 into dotnet:release/8.0-stagingMay 29, 2024

stephentoub deleted the backport99632 branch May 29, 2024 01:41

github-actionsBot locked and limited conversation to collaborators Jun 28, 2024

stephentoub added the Servicing-consider Issue for next servicing release review label May 17, 2024

stephentoub added this to the 8.0.x milestone May 17, 2024

ghost added the area-System.Threading label May 17, 2024

dotnet-policy-serviceBot assigned stephentoub May 17, 2024

build-analysisBot mentioned this pull request May 17, 2024
[8.0] Various WASM hybrid globalization tests failing in many languages #102348
Closed

ericstj added Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels May 22, 2024

Enable DataFlow package in servicing
dfbec3c

ericstj approved these changes May 22, 2024
View reviewed changes

stephentoub merged commit 48a9496 into dotnet:release/8.0-stagingMay 29, 2024

stephentoub deleted the backport99632 branch May 29, 2024 01:41

github-actionsBot locked and limited conversation to collaborators Jun 28, 2024

stephentoub added the Servicing-consider Issue for next servicing release review label May 17, 2024

stephentoub added this to the 8.0.x milestone May 17, 2024

ghost added the area-System.Threading label May 17, 2024

dotnet-policy-serviceBot assigned stephentoub May 17, 2024

build-analysisBot mentioned this pull request May 17, 2024
[8.0] Various WASM hybrid globalization tests failing in many languages #102348
Closed

ericstj added Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels May 22, 2024

Enable DataFlow package in servicing
dfbec3c

ericstj approved these changes May 22, 2024
View reviewed changes

stephentoub merged commit 48a9496 into dotnet:release/8.0-stagingMay 29, 2024

stephentoub deleted the backport99632 branch May 29, 2024 01:41

github-actionsBot locked and limited conversation to collaborators Jun 28, 2024

stephentoub added the Servicing-consider Issue for next servicing release review label May 17, 2024

stephentoub added this to the 8.0.x milestone May 17, 2024

ghost added the area-System.Threading label May 17, 2024

dotnet-policy-serviceBot assigned stephentoub May 17, 2024

build-analysisBot mentioned this pull request May 17, 2024
[8.0] Various WASM hybrid globalization tests failing in many languages #102348
Closed

ericstj added Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels May 22, 2024

Enable DataFlow package in servicing
dfbec3c

ericstj approved these changes May 22, 2024
View reviewed changes

stephentoub merged commit 48a9496 into dotnet:release/8.0-stagingMay 29, 2024

stephentoub deleted the backport99632 branch May 29, 2024 01:41

github-actionsBot locked and limited conversation to collaborators Jun 28, 2024

stephentoub added the Servicing-consider Issue for next servicing release review label May 17, 2024

stephentoub added this to the 8.0.x milestone May 17, 2024

ghost added the area-System.Threading label May 17, 2024

dotnet-policy-serviceBot assigned stephentoub May 17, 2024

build-analysisBot mentioned this pull request May 17, 2024
[8.0] Various WASM hybrid globalization tests failing in many languages #102348
Closed

ericstj added Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels May 22, 2024

Enable DataFlow package in servicing
dfbec3c

ericstj approved these changes May 22, 2024
View reviewed changes

stephentoub merged commit 48a9496 into dotnet:release/8.0-stagingMay 29, 2024

stephentoub deleted the backport99632 branch May 29, 2024 01:41

github-actionsBot locked and limited conversation to collaborators Jun 28, 2024

stephentoub added the Servicing-consider Issue for next servicing release review label May 17, 2024

stephentoub added this to the 8.0.x milestone May 17, 2024

ghost added the area-System.Threading label May 17, 2024

dotnet-policy-serviceBot assigned stephentoub May 17, 2024

build-analysisBot mentioned this pull request May 17, 2024
[8.0] Various WASM hybrid globalization tests failing in many languages #102348
Closed

ericstj added Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels May 22, 2024

Enable DataFlow package in servicing
dfbec3c

ericstj approved these changes May 22, 2024
View reviewed changes

stephentoub merged commit 48a9496 into dotnet:release/8.0-stagingMay 29, 2024

stephentoub deleted the backport99632 branch May 29, 2024 01:41

github-actionsBot locked and limited conversation to collaborators Jun 28, 2024

stephentoub added the Servicing-consider Issue for next servicing release review label May 17, 2024

stephentoub added this to the 8.0.x milestone May 17, 2024

ghost added the area-System.Threading label May 17, 2024

dotnet-policy-serviceBot assigned stephentoub May 17, 2024

build-analysisBot mentioned this pull request May 17, 2024
[8.0] Various WASM hybrid globalization tests failing in many languages #102348
Closed

ericstj added Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels May 22, 2024

Enable DataFlow package in servicing
dfbec3c

ericstj approved these changes May 22, 2024
View reviewed changes

stephentoub merged commit 48a9496 into dotnet:release/8.0-stagingMay 29, 2024

stephentoub deleted the backport99632 branch May 29, 2024 01:41

github-actionsBot locked and limited conversation to collaborators Jun 28, 2024

Uh oh!

Conversation

stephentoub commented May 17, 2024

Customer Impact

Testing

Risk

Uh oh!

dotnet-policy-serviceBot commented May 17, 2024

Uh oh!

ericstj commented May 22, 2024

Uh oh!

ericstj commented May 22, 2024

Uh oh!

ericstj left a comment

Choose a reason for hiding this comment

Uh oh!

stephentoub commented May 29, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

stephentoub commented May 17, 2024

Customer Impact

Testing

Risk

Uh oh!

dotnet-policy-serviceBot commented May 17, 2024

Uh oh!

ericstj commented May 22, 2024

Uh oh!

ericstj commented May 22, 2024

Uh oh!

ericstj left a comment

Choose a reason for hiding this comment

Uh oh!

stephentoub commented May 29, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

stephentoub commented May 17, 2024

Customer Impact

Testing

Risk

Uh oh!

dotnet-policy-serviceBot commented May 17, 2024

Uh oh!

ericstj commented May 22, 2024

Uh oh!

ericstj commented May 22, 2024

Uh oh!

ericstj left a comment

Choose a reason for hiding this comment

Uh oh!

stephentoub commented May 29, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation