[QUIC] Adding `CompleteWritesAsync` by ManickaP · Pull Request #104032 · dotnet/runtime

ManickaP · 2024-06-26T13:37:41Z

Implements async `CompleteWritesAsync` which will eventually replace sync `CompleteWrites`.

The behavior in this PR now mimics combination of CompleteWrites and WritesClosed. This PR also changes behavior of WritesAsync(..., completeWrites: true) to also wait for SEND_SHUTDOWN_COMPLETE (or abort). This PR brings few breaking behavioral changes:

WritesAsync(..., completeWrites: true)
- it's now not possible to separate when the data are buffered (SEND_COMPLETE) and when the completion is ACKed, making the "last write" potentially much longer
- the "last write" now may start throwing in case of local Abort(write) (RESET_STREAM) or remote Abort(read) (STOP_SENDING)
CompleteWritesAsync
- as it's now async, the user doesn't have an easy way to fire-and-forget stream write completion

The behavior is up for discussion, some options:

don't do anything and leave the QuicStream as it was before this change
only report success in CompletWritesAsync and never throw (Exception is still part of CompleteWrites task)

Unfortunately, this effectively reverts #103902 as the WriteAsync now have to chain to async calls in a row...

Fixes#103434

ghost · 2024-06-26T13:37:46Z

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

ghost · 2024-06-26T13:37:47Z

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

dotnet-policy-service · 2024-06-26T13:38:16Z

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

MihaZupan · 2024-06-27T13:49:11Z

Unfortunately, this effectively reverts #103902 as the WriteAsync now have to chain to async calls in a row...

But only for the one final write that has completeWrites set, right?
Could we avoid that by changing

awaitvalueTask.ConfigureAwait(false);if(completeWrites){await_sendTcs.GetFinalTask(this).ConfigureAwait(false);}

to

returncompleteWrites?WaitForTaskAndSendTcsAsync(valueTask):valueTask;asyncWaitForTaskAndSendTcsAsync(ValueTask valueTask){awaitvalueTask.ConfigureAwait(false);await_sendTcs.GetFinalTask(this).ConfigureAwait(false);}

?

We use similar tricks elsewhere in HTTP, e.g. in HttpConnection.WriteAsync.

Equivalent to using WriteAsync with completeWrites: true.

Are we exposing the CompleteWritesAsync method purely as a nicer-to-write helper compared to WriteAsync([], true)?

ManickaP · 2024-06-27T13:57:42Z

But only for the one final write that has completeWrites set, right?

Yes and the trick would work 👍

Are we exposing the CompleteWritesAsync method purely as a nicer-to-write helper compared to WriteAsync([], true)?

Basically yes.

ManickaP · 2024-07-02T12:33:36Z

Closing, decided not to go with the API.

ManickaP · 2024-06-26T13:37:41Z

Implements async `CompleteWritesAsync` which will eventually replace sync `CompleteWrites`.

The behavior in this PR now mimics combination of CompleteWrites and WritesClosed. This PR also changes behavior of WritesAsync(..., completeWrites: true) to also wait for SEND_SHUTDOWN_COMPLETE (or abort). This PR brings few breaking behavioral changes:

WritesAsync(..., completeWrites: true)
- it's now not possible to separate when the data are buffered (SEND_COMPLETE) and when the completion is ACKed, making the "last write" potentially much longer
- the "last write" now may start throwing in case of local Abort(write) (RESET_STREAM) or remote Abort(read) (STOP_SENDING)
CompleteWritesAsync
- as it's now async, the user doesn't have an easy way to fire-and-forget stream write completion

The behavior is up for discussion, some options:

don't do anything and leave the QuicStream as it was before this change
only report success in CompletWritesAsync and never throw (Exception is still part of CompleteWrites task)

Unfortunately, this effectively reverts #103902 as the WriteAsync now have to chain to async calls in a row...

Fixes#103434

ghost · 2024-06-26T13:37:46Z

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

ghost · 2024-06-26T13:37:47Z

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

dotnet-policy-service · 2024-06-26T13:38:16Z

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

MihaZupan · 2024-06-27T13:49:11Z

Unfortunately, this effectively reverts #103902 as the WriteAsync now have to chain to async calls in a row...

But only for the one final write that has completeWrites set, right?
Could we avoid that by changing

awaitvalueTask.ConfigureAwait(false);if(completeWrites){await_sendTcs.GetFinalTask(this).ConfigureAwait(false);}

to

returncompleteWrites?WaitForTaskAndSendTcsAsync(valueTask):valueTask;asyncWaitForTaskAndSendTcsAsync(ValueTask valueTask){awaitvalueTask.ConfigureAwait(false);await_sendTcs.GetFinalTask(this).ConfigureAwait(false);}

?

We use similar tricks elsewhere in HTTP, e.g. in HttpConnection.WriteAsync.

Equivalent to using WriteAsync with completeWrites: true.

Are we exposing the CompleteWritesAsync method purely as a nicer-to-write helper compared to WriteAsync([], true)?

ManickaP · 2024-06-27T13:57:42Z

But only for the one final write that has completeWrites set, right?

Yes and the trick would work 👍

Are we exposing the CompleteWritesAsync method purely as a nicer-to-write helper compared to WriteAsync([], true)?

Basically yes.

ManickaP · 2024-07-02T12:33:36Z

Closing, decided not to go with the API.

ManickaP · 2024-06-26T13:37:41Z

Implements async `CompleteWritesAsync` which will eventually replace sync `CompleteWrites`.

The behavior in this PR now mimics combination of CompleteWrites and WritesClosed. This PR also changes behavior of WritesAsync(..., completeWrites: true) to also wait for SEND_SHUTDOWN_COMPLETE (or abort). This PR brings few breaking behavioral changes:

WritesAsync(..., completeWrites: true)
- it's now not possible to separate when the data are buffered (SEND_COMPLETE) and when the completion is ACKed, making the "last write" potentially much longer
- the "last write" now may start throwing in case of local Abort(write) (RESET_STREAM) or remote Abort(read) (STOP_SENDING)
CompleteWritesAsync
- as it's now async, the user doesn't have an easy way to fire-and-forget stream write completion

The behavior is up for discussion, some options:

don't do anything and leave the QuicStream as it was before this change
only report success in CompletWritesAsync and never throw (Exception is still part of CompleteWrites task)

Unfortunately, this effectively reverts #103902 as the WriteAsync now have to chain to async calls in a row...

Fixes#103434

ghost · 2024-06-26T13:37:46Z

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

ghost · 2024-06-26T13:37:47Z

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

dotnet-policy-service · 2024-06-26T13:38:16Z

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

MihaZupan · 2024-06-27T13:49:11Z

Unfortunately, this effectively reverts #103902 as the WriteAsync now have to chain to async calls in a row...

But only for the one final write that has completeWrites set, right?
Could we avoid that by changing

awaitvalueTask.ConfigureAwait(false);if(completeWrites){await_sendTcs.GetFinalTask(this).ConfigureAwait(false);}

to

returncompleteWrites?WaitForTaskAndSendTcsAsync(valueTask):valueTask;asyncWaitForTaskAndSendTcsAsync(ValueTask valueTask){awaitvalueTask.ConfigureAwait(false);await_sendTcs.GetFinalTask(this).ConfigureAwait(false);}

?

We use similar tricks elsewhere in HTTP, e.g. in HttpConnection.WriteAsync.

Equivalent to using WriteAsync with completeWrites: true.

Are we exposing the CompleteWritesAsync method purely as a nicer-to-write helper compared to WriteAsync([], true)?

ManickaP · 2024-06-27T13:57:42Z

But only for the one final write that has completeWrites set, right?

Yes and the trick would work 👍

Are we exposing the CompleteWritesAsync method purely as a nicer-to-write helper compared to WriteAsync([], true)?

Basically yes.

ManickaP · 2024-07-02T12:33:36Z

Closing, decided not to go with the API.

ManickaP · 2024-06-26T13:37:41Z

Implements async `CompleteWritesAsync` which will eventually replace sync `CompleteWrites`.

The behavior in this PR now mimics combination of CompleteWrites and WritesClosed. This PR also changes behavior of WritesAsync(..., completeWrites: true) to also wait for SEND_SHUTDOWN_COMPLETE (or abort). This PR brings few breaking behavioral changes:

WritesAsync(..., completeWrites: true)
- it's now not possible to separate when the data are buffered (SEND_COMPLETE) and when the completion is ACKed, making the "last write" potentially much longer
- the "last write" now may start throwing in case of local Abort(write) (RESET_STREAM) or remote Abort(read) (STOP_SENDING)
CompleteWritesAsync
- as it's now async, the user doesn't have an easy way to fire-and-forget stream write completion

The behavior is up for discussion, some options:

don't do anything and leave the QuicStream as it was before this change
only report success in CompletWritesAsync and never throw (Exception is still part of CompleteWrites task)

Unfortunately, this effectively reverts #103902 as the WriteAsync now have to chain to async calls in a row...

Fixes#103434

ghost · 2024-06-26T13:37:46Z

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

ghost · 2024-06-26T13:37:47Z

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

dotnet-policy-service · 2024-06-26T13:38:16Z

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

MihaZupan · 2024-06-27T13:49:11Z

Unfortunately, this effectively reverts #103902 as the WriteAsync now have to chain to async calls in a row...

But only for the one final write that has completeWrites set, right?
Could we avoid that by changing

awaitvalueTask.ConfigureAwait(false);if(completeWrites){await_sendTcs.GetFinalTask(this).ConfigureAwait(false);}

to

returncompleteWrites?WaitForTaskAndSendTcsAsync(valueTask):valueTask;asyncWaitForTaskAndSendTcsAsync(ValueTask valueTask){awaitvalueTask.ConfigureAwait(false);await_sendTcs.GetFinalTask(this).ConfigureAwait(false);}

?

We use similar tricks elsewhere in HTTP, e.g. in HttpConnection.WriteAsync.

Equivalent to using WriteAsync with completeWrites: true.

Are we exposing the CompleteWritesAsync method purely as a nicer-to-write helper compared to WriteAsync([], true)?

ManickaP · 2024-06-27T13:57:42Z

But only for the one final write that has completeWrites set, right?

Yes and the trick would work 👍

Are we exposing the CompleteWritesAsync method purely as a nicer-to-write helper compared to WriteAsync([], true)?

Basically yes.

ManickaP · 2024-07-02T12:33:36Z

Closing, decided not to go with the API.

ManickaP · 2024-06-26T13:37:41Z

Implements async `CompleteWritesAsync` which will eventually replace sync `CompleteWrites`.

The behavior in this PR now mimics combination of CompleteWrites and WritesClosed. This PR also changes behavior of WritesAsync(..., completeWrites: true) to also wait for SEND_SHUTDOWN_COMPLETE (or abort). This PR brings few breaking behavioral changes:

WritesAsync(..., completeWrites: true)
- it's now not possible to separate when the data are buffered (SEND_COMPLETE) and when the completion is ACKed, making the "last write" potentially much longer
- the "last write" now may start throwing in case of local Abort(write) (RESET_STREAM) or remote Abort(read) (STOP_SENDING)
CompleteWritesAsync
- as it's now async, the user doesn't have an easy way to fire-and-forget stream write completion

The behavior is up for discussion, some options:

don't do anything and leave the QuicStream as it was before this change
only report success in CompletWritesAsync and never throw (Exception is still part of CompleteWrites task)

Unfortunately, this effectively reverts #103902 as the WriteAsync now have to chain to async calls in a row...

Fixes#103434

ghost · 2024-06-26T13:37:46Z

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

ghost · 2024-06-26T13:37:47Z

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

dotnet-policy-service · 2024-06-26T13:38:16Z

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

MihaZupan · 2024-06-27T13:49:11Z

Unfortunately, this effectively reverts #103902 as the WriteAsync now have to chain to async calls in a row...

But only for the one final write that has completeWrites set, right?
Could we avoid that by changing

awaitvalueTask.ConfigureAwait(false);if(completeWrites){await_sendTcs.GetFinalTask(this).ConfigureAwait(false);}

to

returncompleteWrites?WaitForTaskAndSendTcsAsync(valueTask):valueTask;asyncWaitForTaskAndSendTcsAsync(ValueTask valueTask){awaitvalueTask.ConfigureAwait(false);await_sendTcs.GetFinalTask(this).ConfigureAwait(false);}

?

We use similar tricks elsewhere in HTTP, e.g. in HttpConnection.WriteAsync.

Equivalent to using WriteAsync with completeWrites: true.

Are we exposing the CompleteWritesAsync method purely as a nicer-to-write helper compared to WriteAsync([], true)?

ManickaP · 2024-06-27T13:57:42Z

But only for the one final write that has completeWrites set, right?

Yes and the trick would work 👍

Are we exposing the CompleteWritesAsync method purely as a nicer-to-write helper compared to WriteAsync([], true)?

Basically yes.

ManickaP · 2024-07-02T12:33:36Z

Closing, decided not to go with the API.

ManickaP · 2024-06-26T13:37:41Z

Implements async `CompleteWritesAsync` which will eventually replace sync `CompleteWrites`.

The behavior in this PR now mimics combination of CompleteWrites and WritesClosed. This PR also changes behavior of WritesAsync(..., completeWrites: true) to also wait for SEND_SHUTDOWN_COMPLETE (or abort). This PR brings few breaking behavioral changes:

WritesAsync(..., completeWrites: true)
- it's now not possible to separate when the data are buffered (SEND_COMPLETE) and when the completion is ACKed, making the "last write" potentially much longer
- the "last write" now may start throwing in case of local Abort(write) (RESET_STREAM) or remote Abort(read) (STOP_SENDING)
CompleteWritesAsync
- as it's now async, the user doesn't have an easy way to fire-and-forget stream write completion

The behavior is up for discussion, some options:

don't do anything and leave the QuicStream as it was before this change
only report success in CompletWritesAsync and never throw (Exception is still part of CompleteWrites task)

Unfortunately, this effectively reverts #103902 as the WriteAsync now have to chain to async calls in a row...

Fixes#103434

ghost · 2024-06-26T13:37:46Z

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

ghost · 2024-06-26T13:37:47Z

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

dotnet-policy-service · 2024-06-26T13:38:16Z

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

MihaZupan · 2024-06-27T13:49:11Z

Unfortunately, this effectively reverts #103902 as the WriteAsync now have to chain to async calls in a row...

But only for the one final write that has completeWrites set, right?
Could we avoid that by changing

awaitvalueTask.ConfigureAwait(false);if(completeWrites){await_sendTcs.GetFinalTask(this).ConfigureAwait(false);}

to

returncompleteWrites?WaitForTaskAndSendTcsAsync(valueTask):valueTask;asyncWaitForTaskAndSendTcsAsync(ValueTask valueTask){awaitvalueTask.ConfigureAwait(false);await_sendTcs.GetFinalTask(this).ConfigureAwait(false);}

?

We use similar tricks elsewhere in HTTP, e.g. in HttpConnection.WriteAsync.

Equivalent to using WriteAsync with completeWrites: true.

Are we exposing the CompleteWritesAsync method purely as a nicer-to-write helper compared to WriteAsync([], true)?

ManickaP · 2024-06-27T13:57:42Z

But only for the one final write that has completeWrites set, right?

Yes and the trick would work 👍

Are we exposing the CompleteWritesAsync method purely as a nicer-to-write helper compared to WriteAsync([], true)?

Basically yes.

ManickaP · 2024-07-02T12:33:36Z

Closing, decided not to go with the API.

ManickaP · 2024-06-26T13:37:41Z

Implements async `CompleteWritesAsync` which will eventually replace sync `CompleteWrites`.

The behavior in this PR now mimics combination of CompleteWrites and WritesClosed. This PR also changes behavior of WritesAsync(..., completeWrites: true) to also wait for SEND_SHUTDOWN_COMPLETE (or abort). This PR brings few breaking behavioral changes:

WritesAsync(..., completeWrites: true)
- it's now not possible to separate when the data are buffered (SEND_COMPLETE) and when the completion is ACKed, making the "last write" potentially much longer
- the "last write" now may start throwing in case of local Abort(write) (RESET_STREAM) or remote Abort(read) (STOP_SENDING)
CompleteWritesAsync
- as it's now async, the user doesn't have an easy way to fire-and-forget stream write completion

The behavior is up for discussion, some options:

don't do anything and leave the QuicStream as it was before this change
only report success in CompletWritesAsync and never throw (Exception is still part of CompleteWrites task)

Unfortunately, this effectively reverts #103902 as the WriteAsync now have to chain to async calls in a row...

Fixes#103434

ghost · 2024-06-26T13:37:46Z

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

ghost · 2024-06-26T13:37:47Z

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

dotnet-policy-service · 2024-06-26T13:38:16Z

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

MihaZupan · 2024-06-27T13:49:11Z

Unfortunately, this effectively reverts #103902 as the WriteAsync now have to chain to async calls in a row...

But only for the one final write that has completeWrites set, right?
Could we avoid that by changing

awaitvalueTask.ConfigureAwait(false);if(completeWrites){await_sendTcs.GetFinalTask(this).ConfigureAwait(false);}

to

returncompleteWrites?WaitForTaskAndSendTcsAsync(valueTask):valueTask;asyncWaitForTaskAndSendTcsAsync(ValueTask valueTask){awaitvalueTask.ConfigureAwait(false);await_sendTcs.GetFinalTask(this).ConfigureAwait(false);}

?

We use similar tricks elsewhere in HTTP, e.g. in HttpConnection.WriteAsync.

Equivalent to using WriteAsync with completeWrites: true.

Are we exposing the CompleteWritesAsync method purely as a nicer-to-write helper compared to WriteAsync([], true)?

ManickaP · 2024-06-27T13:57:42Z

But only for the one final write that has completeWrites set, right?

Yes and the trick would work 👍

Are we exposing the CompleteWritesAsync method purely as a nicer-to-write helper compared to WriteAsync([], true)?

Basically yes.

ManickaP · 2024-07-02T12:33:36Z

Closing, decided not to go with the API.

ManickaP · 2024-06-26T13:37:41Z

Implements async `CompleteWritesAsync` which will eventually replace sync `CompleteWrites`.

The behavior in this PR now mimics combination of CompleteWrites and WritesClosed. This PR also changes behavior of WritesAsync(..., completeWrites: true) to also wait for SEND_SHUTDOWN_COMPLETE (or abort). This PR brings few breaking behavioral changes:

WritesAsync(..., completeWrites: true)
- it's now not possible to separate when the data are buffered (SEND_COMPLETE) and when the completion is ACKed, making the "last write" potentially much longer
- the "last write" now may start throwing in case of local Abort(write) (RESET_STREAM) or remote Abort(read) (STOP_SENDING)
CompleteWritesAsync
- as it's now async, the user doesn't have an easy way to fire-and-forget stream write completion

The behavior is up for discussion, some options:

don't do anything and leave the QuicStream as it was before this change
only report success in CompletWritesAsync and never throw (Exception is still part of CompleteWrites task)

Unfortunately, this effectively reverts #103902 as the WriteAsync now have to chain to async calls in a row...

Fixes#103434

ghost · 2024-06-26T13:37:46Z

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

ghost · 2024-06-26T13:37:47Z

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

dotnet-policy-service · 2024-06-26T13:38:16Z

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

MihaZupan · 2024-06-27T13:49:11Z

Unfortunately, this effectively reverts #103902 as the WriteAsync now have to chain to async calls in a row...

But only for the one final write that has completeWrites set, right?
Could we avoid that by changing

awaitvalueTask.ConfigureAwait(false);if(completeWrites){await_sendTcs.GetFinalTask(this).ConfigureAwait(false);}

to

returncompleteWrites?WaitForTaskAndSendTcsAsync(valueTask):valueTask;asyncWaitForTaskAndSendTcsAsync(ValueTask valueTask){awaitvalueTask.ConfigureAwait(false);await_sendTcs.GetFinalTask(this).ConfigureAwait(false);}

?

We use similar tricks elsewhere in HTTP, e.g. in HttpConnection.WriteAsync.

Equivalent to using WriteAsync with completeWrites: true.

Are we exposing the CompleteWritesAsync method purely as a nicer-to-write helper compared to WriteAsync([], true)?

ManickaP · 2024-06-27T13:57:42Z

But only for the one final write that has completeWrites set, right?

Yes and the trick would work 👍

Are we exposing the CompleteWritesAsync method purely as a nicer-to-write helper compared to WriteAsync([], true)?

Basically yes.

ManickaP · 2024-07-02T12:33:36Z

Closing, decided not to go with the API.

CompletWritesAsync
1efe232

ghost added area-System.Net.Quic new-api-needs-documentation labels Jun 26, 2024

dotnet-policy-serviceBot assigned ManickaP Jun 26, 2024

ManickaP requested review from a team, CarnaViire and rzikm June 26, 2024 13:37

ManickaP mentioned this pull request Jun 26, 2024
[H/3] Wait for WritesClosed and Dispose as fire-and-forget #104035
Merged

rzikm changed the title ~~[QUIC] Adding CompletWritesAsync~~[QUIC] Adding CompleteWritesAsyncJun 27, 2024

ManickaP closed this Jul 2, 2024

ManickaP deleted the quic-complete-writes-async branch July 2, 2024 14:57

github-actionsBot locked and limited conversation to collaborators Aug 2, 2024

karelz added this to the 9.0.0 milestone Sep 3, 2024

CompletWritesAsync
1efe232

ghost added area-System.Net.Quic new-api-needs-documentation labels Jun 26, 2024

dotnet-policy-serviceBot assigned ManickaP Jun 26, 2024

ManickaP requested review from a team, CarnaViire and rzikm June 26, 2024 13:37

ManickaP mentioned this pull request Jun 26, 2024
[H/3] Wait for WritesClosed and Dispose as fire-and-forget #104035
Merged

rzikm changed the title ~~[QUIC] Adding CompletWritesAsync~~[QUIC] Adding CompleteWritesAsyncJun 27, 2024

ManickaP closed this Jul 2, 2024

ManickaP deleted the quic-complete-writes-async branch July 2, 2024 14:57

github-actionsBot locked and limited conversation to collaborators Aug 2, 2024

karelz added this to the 9.0.0 milestone Sep 3, 2024

CompletWritesAsync
1efe232

ghost added area-System.Net.Quic new-api-needs-documentation labels Jun 26, 2024

dotnet-policy-serviceBot assigned ManickaP Jun 26, 2024

ManickaP requested review from a team, CarnaViire and rzikm June 26, 2024 13:37

ManickaP mentioned this pull request Jun 26, 2024
[H/3] Wait for WritesClosed and Dispose as fire-and-forget #104035
Merged

rzikm changed the title ~~[QUIC] Adding CompletWritesAsync~~[QUIC] Adding CompleteWritesAsyncJun 27, 2024

ManickaP closed this Jul 2, 2024

ManickaP deleted the quic-complete-writes-async branch July 2, 2024 14:57

github-actionsBot locked and limited conversation to collaborators Aug 2, 2024

karelz added this to the 9.0.0 milestone Sep 3, 2024

CompletWritesAsync
1efe232

ghost added area-System.Net.Quic new-api-needs-documentation labels Jun 26, 2024

dotnet-policy-serviceBot assigned ManickaP Jun 26, 2024

ManickaP requested review from a team, CarnaViire and rzikm June 26, 2024 13:37

ManickaP mentioned this pull request Jun 26, 2024
[H/3] Wait for WritesClosed and Dispose as fire-and-forget #104035
Merged

rzikm changed the title ~~[QUIC] Adding CompletWritesAsync~~[QUIC] Adding CompleteWritesAsyncJun 27, 2024

ManickaP closed this Jul 2, 2024

ManickaP deleted the quic-complete-writes-async branch July 2, 2024 14:57

github-actionsBot locked and limited conversation to collaborators Aug 2, 2024

karelz added this to the 9.0.0 milestone Sep 3, 2024

CompletWritesAsync
1efe232

ghost added area-System.Net.Quic new-api-needs-documentation labels Jun 26, 2024

dotnet-policy-serviceBot assigned ManickaP Jun 26, 2024

ManickaP requested review from a team, CarnaViire and rzikm June 26, 2024 13:37

ManickaP mentioned this pull request Jun 26, 2024
[H/3] Wait for WritesClosed and Dispose as fire-and-forget #104035
Merged

rzikm changed the title ~~[QUIC] Adding CompletWritesAsync~~[QUIC] Adding CompleteWritesAsyncJun 27, 2024

ManickaP closed this Jul 2, 2024

ManickaP deleted the quic-complete-writes-async branch July 2, 2024 14:57

github-actionsBot locked and limited conversation to collaborators Aug 2, 2024

karelz added this to the 9.0.0 milestone Sep 3, 2024

CompletWritesAsync
1efe232

ghost added area-System.Net.Quic new-api-needs-documentation labels Jun 26, 2024

dotnet-policy-serviceBot assigned ManickaP Jun 26, 2024

ManickaP requested review from a team, CarnaViire and rzikm June 26, 2024 13:37

ManickaP mentioned this pull request Jun 26, 2024
[H/3] Wait for WritesClosed and Dispose as fire-and-forget #104035
Merged

rzikm changed the title ~~[QUIC] Adding CompletWritesAsync~~[QUIC] Adding CompleteWritesAsyncJun 27, 2024

ManickaP closed this Jul 2, 2024

ManickaP deleted the quic-complete-writes-async branch July 2, 2024 14:57

github-actionsBot locked and limited conversation to collaborators Aug 2, 2024

karelz added this to the 9.0.0 milestone Sep 3, 2024

CompletWritesAsync
1efe232

ghost added area-System.Net.Quic new-api-needs-documentation labels Jun 26, 2024

dotnet-policy-serviceBot assigned ManickaP Jun 26, 2024

ManickaP requested review from a team, CarnaViire and rzikm June 26, 2024 13:37

ManickaP mentioned this pull request Jun 26, 2024
[H/3] Wait for WritesClosed and Dispose as fire-and-forget #104035
Merged

rzikm changed the title ~~[QUIC] Adding CompletWritesAsync~~[QUIC] Adding CompleteWritesAsyncJun 27, 2024

ManickaP closed this Jul 2, 2024

ManickaP deleted the quic-complete-writes-async branch July 2, 2024 14:57

github-actionsBot locked and limited conversation to collaborators Aug 2, 2024

karelz added this to the 9.0.0 milestone Sep 3, 2024

CompletWritesAsync
1efe232

ghost added area-System.Net.Quic new-api-needs-documentation labels Jun 26, 2024

dotnet-policy-serviceBot assigned ManickaP Jun 26, 2024

ManickaP requested review from a team, CarnaViire and rzikm June 26, 2024 13:37

ManickaP mentioned this pull request Jun 26, 2024
[H/3] Wait for WritesClosed and Dispose as fire-and-forget #104035
Merged

rzikm changed the title ~~[QUIC] Adding CompletWritesAsync~~[QUIC] Adding CompleteWritesAsyncJun 27, 2024

ManickaP closed this Jul 2, 2024

ManickaP deleted the quic-complete-writes-async branch July 2, 2024 14:57

github-actionsBot locked and limited conversation to collaborators Aug 2, 2024

karelz added this to the 9.0.0 milestone Sep 3, 2024

Uh oh!

Conversation

ManickaP commented Jun 26, 2024

Implements async CompleteWritesAsync which will eventually replace sync CompleteWrites.

Uh oh!

ghost commented Jun 26, 2024

Uh oh!

ghost commented Jun 26, 2024

Uh oh!

dotnet-policy-serviceBot commented Jun 26, 2024

Uh oh!

MihaZupan commented Jun 27, 2024

Uh oh!

ManickaP commented Jun 27, 2024

Uh oh!

ManickaP commented Jul 2, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

ManickaP commented Jun 26, 2024

Implements async CompleteWritesAsync which will eventually replace sync CompleteWrites.

Uh oh!

ghost commented Jun 26, 2024

Uh oh!

ghost commented Jun 26, 2024

Uh oh!

dotnet-policy-serviceBot commented Jun 26, 2024

Uh oh!

MihaZupan commented Jun 27, 2024

Uh oh!

ManickaP commented Jun 27, 2024

Uh oh!

ManickaP commented Jul 2, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

ManickaP commented Jun 26, 2024

Implements async CompleteWritesAsync which will eventually replace sync CompleteWrites.

Uh oh!

ghost commented Jun 26, 2024

Uh oh!

ghost commented Jun 26, 2024

Uh oh!

dotnet-policy-serviceBot commented Jun 26, 2024

Uh oh!

MihaZupan commented Jun 27, 2024

Uh oh!

ManickaP commented Jun 27, 2024

Uh oh!

ManickaP commented Jul 2, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

ManickaP commented Jun 26, 2024

Implements async CompleteWritesAsync which will eventually replace sync CompleteWrites.

Uh oh!

Implements async `CompleteWritesAsync` which will eventually replace sync `CompleteWrites`.

Implements async `CompleteWritesAsync` which will eventually replace sync `CompleteWrites`.

Implements async `CompleteWritesAsync` which will eventually replace sync `CompleteWrites`.

Implements async `CompleteWritesAsync` which will eventually replace sync `CompleteWrites`.

Implements async `CompleteWritesAsync` which will eventually replace sync `CompleteWrites`.