improve accuracy of Expect100Continue_WaitsExpectedPeriodOfTimeBeforeSendingContent test by wfurt · Pull Request #44053 · dotnet/runtime

wfurt · 2020-10-30T06:31:54Z

From the name of the test, I assume we are trying to verify that provided Expect100ContinueTimeout is respected e.g. we wait longer than default 1s.

Right now the test does it be measuring whole request/response and verifying duration within arbitrary time range.
With delay of 3s and fudge of 20 we expect everything to finish within 1 minute. From test failures are are sometimes over that - with max duration ~ 1:30 -1:40.

This PR is changing the test logic. Instead of measuring the whole duration, I measure delay between start and sending content e.g. call to SerializeToStreamAsync(). It should be at least expected delay - and could be more depending on system load and other environmental conditions. With default 1s, that should be sufficient verification that the delay actually works.

I originally used Stopwatch and I saw occasion failures when elapsed time would be slightly shorter e.g. 2995-2999.
I solved by using Environment.TickCount64 instead as it seems to use semi coarse base as Timer class.

fixes#41530
fixes#41953

…SendingContent test

ghost · 2020-10-30T06:31:56Z

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

ManickaP

LGTM, thanks!

wfurt · 2020-10-31T17:11:41Z

/azp run runtime-libraries-coreclr outerloop

azure-pipelines · 2020-10-31T17:11:55Z

Azure Pipelines successfully started running 1 pipeline(s).

wfurt · 2020-11-03T00:45:56Z

all failures seems unrelated. running outer loop one more time to be sure.

wfurt · 2020-11-03T00:46:01Z

/azp run runtime-libraries-coreclr outerloop

azure-pipelines · 2020-11-03T00:46:16Z

Azure Pipelines successfully started running 1 pipeline(s).

geoffkizer · 2020-11-03T18:25:58Z

-
- Assert.InRange(sw.Elapsed, delay - TimeSpan.FromSeconds(.5), delay * 20); // arbitrary wiggle room
+ long elapsed = content.Ticks - start;
+ Assert.True(elapsed >= delay.TotalMilliseconds);


You might want to have a small amount of leeway here in checking that elapsed >= delay, just in case of timing weirdness -- looks like the test previously had 0.5s of leeway?
If it's reliable as is, then maybe no leeway is necessary.

geoffkizer

The test logic is definitely better this way, thanks.

wfurt · 2020-10-30T06:31:54Z

From the name of the test, I assume we are trying to verify that provided Expect100ContinueTimeout is respected e.g. we wait longer than default 1s.

Right now the test does it be measuring whole request/response and verifying duration within arbitrary time range.
With delay of 3s and fudge of 20 we expect everything to finish within 1 minute. From test failures are are sometimes over that - with max duration ~ 1:30 -1:40.

This PR is changing the test logic. Instead of measuring the whole duration, I measure delay between start and sending content e.g. call to SerializeToStreamAsync(). It should be at least expected delay - and could be more depending on system load and other environmental conditions. With default 1s, that should be sufficient verification that the delay actually works.

I originally used Stopwatch and I saw occasion failures when elapsed time would be slightly shorter e.g. 2995-2999.
I solved by using Environment.TickCount64 instead as it seems to use semi coarse base as Timer class.

fixes#41530
fixes#41953

…SendingContent test

ghost · 2020-10-30T06:31:56Z

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

ManickaP

LGTM, thanks!

wfurt · 2020-10-31T17:11:41Z

/azp run runtime-libraries-coreclr outerloop

azure-pipelines · 2020-10-31T17:11:55Z

Azure Pipelines successfully started running 1 pipeline(s).

wfurt · 2020-11-03T00:45:56Z

all failures seems unrelated. running outer loop one more time to be sure.

wfurt · 2020-11-03T00:46:01Z

/azp run runtime-libraries-coreclr outerloop

azure-pipelines · 2020-11-03T00:46:16Z

Azure Pipelines successfully started running 1 pipeline(s).

geoffkizer · 2020-11-03T18:25:58Z

-
- Assert.InRange(sw.Elapsed, delay - TimeSpan.FromSeconds(.5), delay * 20); // arbitrary wiggle room
+ long elapsed = content.Ticks - start;
+ Assert.True(elapsed >= delay.TotalMilliseconds);


You might want to have a small amount of leeway here in checking that elapsed >= delay, just in case of timing weirdness -- looks like the test previously had 0.5s of leeway?
If it's reliable as is, then maybe no leeway is necessary.

geoffkizer

The test logic is definitely better this way, thanks.

wfurt · 2020-10-30T06:31:54Z

From the name of the test, I assume we are trying to verify that provided Expect100ContinueTimeout is respected e.g. we wait longer than default 1s.

Right now the test does it be measuring whole request/response and verifying duration within arbitrary time range.
With delay of 3s and fudge of 20 we expect everything to finish within 1 minute. From test failures are are sometimes over that - with max duration ~ 1:30 -1:40.

This PR is changing the test logic. Instead of measuring the whole duration, I measure delay between start and sending content e.g. call to SerializeToStreamAsync(). It should be at least expected delay - and could be more depending on system load and other environmental conditions. With default 1s, that should be sufficient verification that the delay actually works.

I originally used Stopwatch and I saw occasion failures when elapsed time would be slightly shorter e.g. 2995-2999.
I solved by using Environment.TickCount64 instead as it seems to use semi coarse base as Timer class.

fixes#41530
fixes#41953

…SendingContent test

ghost · 2020-10-30T06:31:56Z

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

ManickaP

LGTM, thanks!

wfurt · 2020-10-31T17:11:41Z

/azp run runtime-libraries-coreclr outerloop

azure-pipelines · 2020-10-31T17:11:55Z

Azure Pipelines successfully started running 1 pipeline(s).

wfurt · 2020-11-03T00:45:56Z

all failures seems unrelated. running outer loop one more time to be sure.

wfurt · 2020-11-03T00:46:01Z

/azp run runtime-libraries-coreclr outerloop

azure-pipelines · 2020-11-03T00:46:16Z

Azure Pipelines successfully started running 1 pipeline(s).

geoffkizer · 2020-11-03T18:25:58Z

-
- Assert.InRange(sw.Elapsed, delay - TimeSpan.FromSeconds(.5), delay * 20); // arbitrary wiggle room
+ long elapsed = content.Ticks - start;
+ Assert.True(elapsed >= delay.TotalMilliseconds);


You might want to have a small amount of leeway here in checking that elapsed >= delay, just in case of timing weirdness -- looks like the test previously had 0.5s of leeway?
If it's reliable as is, then maybe no leeway is necessary.

geoffkizer

The test logic is definitely better this way, thanks.

wfurt · 2020-10-30T06:31:54Z

From the name of the test, I assume we are trying to verify that provided Expect100ContinueTimeout is respected e.g. we wait longer than default 1s.

Right now the test does it be measuring whole request/response and verifying duration within arbitrary time range.
With delay of 3s and fudge of 20 we expect everything to finish within 1 minute. From test failures are are sometimes over that - with max duration ~ 1:30 -1:40.

This PR is changing the test logic. Instead of measuring the whole duration, I measure delay between start and sending content e.g. call to SerializeToStreamAsync(). It should be at least expected delay - and could be more depending on system load and other environmental conditions. With default 1s, that should be sufficient verification that the delay actually works.

I originally used Stopwatch and I saw occasion failures when elapsed time would be slightly shorter e.g. 2995-2999.
I solved by using Environment.TickCount64 instead as it seems to use semi coarse base as Timer class.

fixes#41530
fixes#41953

…SendingContent test

ghost · 2020-10-30T06:31:56Z

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

ManickaP

LGTM, thanks!

wfurt · 2020-10-31T17:11:41Z

/azp run runtime-libraries-coreclr outerloop

azure-pipelines · 2020-10-31T17:11:55Z

Azure Pipelines successfully started running 1 pipeline(s).

wfurt · 2020-11-03T00:45:56Z

all failures seems unrelated. running outer loop one more time to be sure.

wfurt · 2020-11-03T00:46:01Z

/azp run runtime-libraries-coreclr outerloop

azure-pipelines · 2020-11-03T00:46:16Z

Azure Pipelines successfully started running 1 pipeline(s).

geoffkizer · 2020-11-03T18:25:58Z

-
- Assert.InRange(sw.Elapsed, delay - TimeSpan.FromSeconds(.5), delay * 20); // arbitrary wiggle room
+ long elapsed = content.Ticks - start;
+ Assert.True(elapsed >= delay.TotalMilliseconds);


You might want to have a small amount of leeway here in checking that elapsed >= delay, just in case of timing weirdness -- looks like the test previously had 0.5s of leeway?
If it's reliable as is, then maybe no leeway is necessary.

geoffkizer

The test logic is definitely better this way, thanks.

wfurt · 2020-10-30T06:31:54Z

From the name of the test, I assume we are trying to verify that provided Expect100ContinueTimeout is respected e.g. we wait longer than default 1s.

Right now the test does it be measuring whole request/response and verifying duration within arbitrary time range.
With delay of 3s and fudge of 20 we expect everything to finish within 1 minute. From test failures are are sometimes over that - with max duration ~ 1:30 -1:40.

This PR is changing the test logic. Instead of measuring the whole duration, I measure delay between start and sending content e.g. call to SerializeToStreamAsync(). It should be at least expected delay - and could be more depending on system load and other environmental conditions. With default 1s, that should be sufficient verification that the delay actually works.

I originally used Stopwatch and I saw occasion failures when elapsed time would be slightly shorter e.g. 2995-2999.
I solved by using Environment.TickCount64 instead as it seems to use semi coarse base as Timer class.

fixes#41530
fixes#41953

…SendingContent test

ghost · 2020-10-30T06:31:56Z

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

ManickaP

LGTM, thanks!

wfurt · 2020-10-31T17:11:41Z

/azp run runtime-libraries-coreclr outerloop

azure-pipelines · 2020-10-31T17:11:55Z

Azure Pipelines successfully started running 1 pipeline(s).

wfurt · 2020-11-03T00:45:56Z

all failures seems unrelated. running outer loop one more time to be sure.

wfurt · 2020-11-03T00:46:01Z

/azp run runtime-libraries-coreclr outerloop

azure-pipelines · 2020-11-03T00:46:16Z

Azure Pipelines successfully started running 1 pipeline(s).

geoffkizer · 2020-11-03T18:25:58Z

-
- Assert.InRange(sw.Elapsed, delay - TimeSpan.FromSeconds(.5), delay * 20); // arbitrary wiggle room
+ long elapsed = content.Ticks - start;
+ Assert.True(elapsed >= delay.TotalMilliseconds);


You might want to have a small amount of leeway here in checking that elapsed >= delay, just in case of timing weirdness -- looks like the test previously had 0.5s of leeway?
If it's reliable as is, then maybe no leeway is necessary.

geoffkizer

The test logic is definitely better this way, thanks.

wfurt · 2020-10-30T06:31:54Z

From the name of the test, I assume we are trying to verify that provided Expect100ContinueTimeout is respected e.g. we wait longer than default 1s.

Right now the test does it be measuring whole request/response and verifying duration within arbitrary time range.
With delay of 3s and fudge of 20 we expect everything to finish within 1 minute. From test failures are are sometimes over that - with max duration ~ 1:30 -1:40.

This PR is changing the test logic. Instead of measuring the whole duration, I measure delay between start and sending content e.g. call to SerializeToStreamAsync(). It should be at least expected delay - and could be more depending on system load and other environmental conditions. With default 1s, that should be sufficient verification that the delay actually works.

I originally used Stopwatch and I saw occasion failures when elapsed time would be slightly shorter e.g. 2995-2999.
I solved by using Environment.TickCount64 instead as it seems to use semi coarse base as Timer class.

fixes#41530
fixes#41953

…SendingContent test

ghost · 2020-10-30T06:31:56Z

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

ManickaP

LGTM, thanks!

wfurt · 2020-10-31T17:11:41Z

/azp run runtime-libraries-coreclr outerloop

azure-pipelines · 2020-10-31T17:11:55Z

Azure Pipelines successfully started running 1 pipeline(s).

wfurt · 2020-11-03T00:45:56Z

all failures seems unrelated. running outer loop one more time to be sure.

wfurt · 2020-11-03T00:46:01Z

/azp run runtime-libraries-coreclr outerloop

azure-pipelines · 2020-11-03T00:46:16Z

Azure Pipelines successfully started running 1 pipeline(s).

geoffkizer · 2020-11-03T18:25:58Z

-
- Assert.InRange(sw.Elapsed, delay - TimeSpan.FromSeconds(.5), delay * 20); // arbitrary wiggle room
+ long elapsed = content.Ticks - start;
+ Assert.True(elapsed >= delay.TotalMilliseconds);


You might want to have a small amount of leeway here in checking that elapsed >= delay, just in case of timing weirdness -- looks like the test previously had 0.5s of leeway?
If it's reliable as is, then maybe no leeway is necessary.

geoffkizer

The test logic is definitely better this way, thanks.

wfurt · 2020-10-30T06:31:54Z

From the name of the test, I assume we are trying to verify that provided Expect100ContinueTimeout is respected e.g. we wait longer than default 1s.

Right now the test does it be measuring whole request/response and verifying duration within arbitrary time range.
With delay of 3s and fudge of 20 we expect everything to finish within 1 minute. From test failures are are sometimes over that - with max duration ~ 1:30 -1:40.

This PR is changing the test logic. Instead of measuring the whole duration, I measure delay between start and sending content e.g. call to SerializeToStreamAsync(). It should be at least expected delay - and could be more depending on system load and other environmental conditions. With default 1s, that should be sufficient verification that the delay actually works.

I originally used Stopwatch and I saw occasion failures when elapsed time would be slightly shorter e.g. 2995-2999.
I solved by using Environment.TickCount64 instead as it seems to use semi coarse base as Timer class.

fixes#41530
fixes#41953

…SendingContent test

ghost · 2020-10-30T06:31:56Z

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

ManickaP

LGTM, thanks!

wfurt · 2020-10-31T17:11:41Z

/azp run runtime-libraries-coreclr outerloop

azure-pipelines · 2020-10-31T17:11:55Z

Azure Pipelines successfully started running 1 pipeline(s).

wfurt · 2020-11-03T00:45:56Z

all failures seems unrelated. running outer loop one more time to be sure.

wfurt · 2020-11-03T00:46:01Z

/azp run runtime-libraries-coreclr outerloop

azure-pipelines · 2020-11-03T00:46:16Z

Azure Pipelines successfully started running 1 pipeline(s).

geoffkizer · 2020-11-03T18:25:58Z

-
- Assert.InRange(sw.Elapsed, delay - TimeSpan.FromSeconds(.5), delay * 20); // arbitrary wiggle room
+ long elapsed = content.Ticks - start;
+ Assert.True(elapsed >= delay.TotalMilliseconds);


You might want to have a small amount of leeway here in checking that elapsed >= delay, just in case of timing weirdness -- looks like the test previously had 0.5s of leeway?
If it's reliable as is, then maybe no leeway is necessary.

geoffkizer

The test logic is definitely better this way, thanks.

wfurt · 2020-10-30T06:31:54Z

From the name of the test, I assume we are trying to verify that provided Expect100ContinueTimeout is respected e.g. we wait longer than default 1s.

Right now the test does it be measuring whole request/response and verifying duration within arbitrary time range.
With delay of 3s and fudge of 20 we expect everything to finish within 1 minute. From test failures are are sometimes over that - with max duration ~ 1:30 -1:40.

This PR is changing the test logic. Instead of measuring the whole duration, I measure delay between start and sending content e.g. call to SerializeToStreamAsync(). It should be at least expected delay - and could be more depending on system load and other environmental conditions. With default 1s, that should be sufficient verification that the delay actually works.

I originally used Stopwatch and I saw occasion failures when elapsed time would be slightly shorter e.g. 2995-2999.
I solved by using Environment.TickCount64 instead as it seems to use semi coarse base as Timer class.

fixes#41530
fixes#41953

…SendingContent test

ghost · 2020-10-30T06:31:56Z

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

ManickaP

LGTM, thanks!

wfurt · 2020-10-31T17:11:41Z

/azp run runtime-libraries-coreclr outerloop

azure-pipelines · 2020-10-31T17:11:55Z

Azure Pipelines successfully started running 1 pipeline(s).

wfurt · 2020-11-03T00:45:56Z

all failures seems unrelated. running outer loop one more time to be sure.

wfurt · 2020-11-03T00:46:01Z

/azp run runtime-libraries-coreclr outerloop

azure-pipelines · 2020-11-03T00:46:16Z

Azure Pipelines successfully started running 1 pipeline(s).

geoffkizer · 2020-11-03T18:25:58Z

-
- Assert.InRange(sw.Elapsed, delay - TimeSpan.FromSeconds(.5), delay * 20); // arbitrary wiggle room
+ long elapsed = content.Ticks - start;
+ Assert.True(elapsed >= delay.TotalMilliseconds);


You might want to have a small amount of leeway here in checking that elapsed >= delay, just in case of timing weirdness -- looks like the test previously had 0.5s of leeway?
If it's reliable as is, then maybe no leeway is necessary.

geoffkizer

The test logic is definitely better this way, thanks.

improve accuracy of Expect100Continue_WaitsExpectedPeriodOfTimeBefore…
705d605
…SendingContent test

wfurt added area-System.Net.Http test-bug Problem in test source code (most likely) labels Oct 30, 2020

wfurt requested a review from a teamOctober 30, 2020 06:31

wfurt self-assigned this Oct 30, 2020

ManickaP approved these changes Oct 30, 2020
View reviewed changes

Comment threadsrc/libraries/System.Net.Http/tests/FunctionalTests/HttpClientHandlerTest.Cancellation.cs Outdated
Comment threadsrc/libraries/System.Net.Http/tests/FunctionalTests/HttpClientHandlerTest.Cancellation.cs

feedback from review
42dde1d

runfoappBot mentioned this pull request Oct 30, 2020
System.Buffers.ArrayPool.Tests.CollectionTests.PollingEventFires failing in CI #44037
Closed

geoffkizer reviewed Nov 3, 2020
View reviewed changes

geoffkizer approved these changes Nov 3, 2020
View reviewed changes

wfurt merged commit 6ca1f20 into dotnet:masterNov 3, 2020

wfurt deleted the 100expect_41530 branch November 3, 2020 19:35

ghost locked as resolved and limited conversation to collaborators Dec 6, 2020

karelz added this to the 6.0.0 milestone Jan 26, 2021

improve accuracy of Expect100Continue_WaitsExpectedPeriodOfTimeBefore…
705d605
…SendingContent test

wfurt added area-System.Net.Http test-bug Problem in test source code (most likely) labels Oct 30, 2020

wfurt requested a review from a teamOctober 30, 2020 06:31

wfurt self-assigned this Oct 30, 2020

ManickaP approved these changes Oct 30, 2020
View reviewed changes

Comment threadsrc/libraries/System.Net.Http/tests/FunctionalTests/HttpClientHandlerTest.Cancellation.cs Outdated
Comment threadsrc/libraries/System.Net.Http/tests/FunctionalTests/HttpClientHandlerTest.Cancellation.cs

feedback from review
42dde1d

runfoappBot mentioned this pull request Oct 30, 2020
System.Buffers.ArrayPool.Tests.CollectionTests.PollingEventFires failing in CI #44037
Closed

geoffkizer reviewed Nov 3, 2020
View reviewed changes

geoffkizer approved these changes Nov 3, 2020
View reviewed changes

wfurt merged commit 6ca1f20 into dotnet:masterNov 3, 2020

wfurt deleted the 100expect_41530 branch November 3, 2020 19:35

ghost locked as resolved and limited conversation to collaborators Dec 6, 2020

karelz added this to the 6.0.0 milestone Jan 26, 2021

improve accuracy of Expect100Continue_WaitsExpectedPeriodOfTimeBefore…
705d605
…SendingContent test

wfurt added area-System.Net.Http test-bug Problem in test source code (most likely) labels Oct 30, 2020

wfurt requested a review from a teamOctober 30, 2020 06:31

wfurt self-assigned this Oct 30, 2020

ManickaP approved these changes Oct 30, 2020
View reviewed changes

Comment threadsrc/libraries/System.Net.Http/tests/FunctionalTests/HttpClientHandlerTest.Cancellation.cs Outdated
Comment threadsrc/libraries/System.Net.Http/tests/FunctionalTests/HttpClientHandlerTest.Cancellation.cs

feedback from review
42dde1d

runfoappBot mentioned this pull request Oct 30, 2020
System.Buffers.ArrayPool.Tests.CollectionTests.PollingEventFires failing in CI #44037
Closed

geoffkizer reviewed Nov 3, 2020
View reviewed changes

geoffkizer approved these changes Nov 3, 2020
View reviewed changes

wfurt merged commit 6ca1f20 into dotnet:masterNov 3, 2020

wfurt deleted the 100expect_41530 branch November 3, 2020 19:35

ghost locked as resolved and limited conversation to collaborators Dec 6, 2020

karelz added this to the 6.0.0 milestone Jan 26, 2021

improve accuracy of Expect100Continue_WaitsExpectedPeriodOfTimeBefore…
705d605
…SendingContent test

wfurt added area-System.Net.Http test-bug Problem in test source code (most likely) labels Oct 30, 2020

wfurt requested a review from a teamOctober 30, 2020 06:31

wfurt self-assigned this Oct 30, 2020

ManickaP approved these changes Oct 30, 2020
View reviewed changes

Comment threadsrc/libraries/System.Net.Http/tests/FunctionalTests/HttpClientHandlerTest.Cancellation.cs Outdated
Comment threadsrc/libraries/System.Net.Http/tests/FunctionalTests/HttpClientHandlerTest.Cancellation.cs

feedback from review
42dde1d

runfoappBot mentioned this pull request Oct 30, 2020
System.Buffers.ArrayPool.Tests.CollectionTests.PollingEventFires failing in CI #44037
Closed

geoffkizer reviewed Nov 3, 2020
View reviewed changes

geoffkizer approved these changes Nov 3, 2020
View reviewed changes

wfurt merged commit 6ca1f20 into dotnet:masterNov 3, 2020

wfurt deleted the 100expect_41530 branch November 3, 2020 19:35

ghost locked as resolved and limited conversation to collaborators Dec 6, 2020

karelz added this to the 6.0.0 milestone Jan 26, 2021

improve accuracy of Expect100Continue_WaitsExpectedPeriodOfTimeBefore…
705d605
…SendingContent test

wfurt added area-System.Net.Http test-bug Problem in test source code (most likely) labels Oct 30, 2020

wfurt requested a review from a teamOctober 30, 2020 06:31

wfurt self-assigned this Oct 30, 2020

ManickaP approved these changes Oct 30, 2020
View reviewed changes

Comment threadsrc/libraries/System.Net.Http/tests/FunctionalTests/HttpClientHandlerTest.Cancellation.cs Outdated
Comment threadsrc/libraries/System.Net.Http/tests/FunctionalTests/HttpClientHandlerTest.Cancellation.cs

feedback from review
42dde1d

runfoappBot mentioned this pull request Oct 30, 2020
System.Buffers.ArrayPool.Tests.CollectionTests.PollingEventFires failing in CI #44037
Closed

geoffkizer reviewed Nov 3, 2020
View reviewed changes

geoffkizer approved these changes Nov 3, 2020
View reviewed changes

wfurt merged commit 6ca1f20 into dotnet:masterNov 3, 2020

wfurt deleted the 100expect_41530 branch November 3, 2020 19:35

ghost locked as resolved and limited conversation to collaborators Dec 6, 2020

karelz added this to the 6.0.0 milestone Jan 26, 2021

improve accuracy of Expect100Continue_WaitsExpectedPeriodOfTimeBefore…
705d605
…SendingContent test

wfurt added area-System.Net.Http test-bug Problem in test source code (most likely) labels Oct 30, 2020

wfurt requested a review from a teamOctober 30, 2020 06:31

wfurt self-assigned this Oct 30, 2020

ManickaP approved these changes Oct 30, 2020
View reviewed changes

Comment threadsrc/libraries/System.Net.Http/tests/FunctionalTests/HttpClientHandlerTest.Cancellation.cs Outdated
Comment threadsrc/libraries/System.Net.Http/tests/FunctionalTests/HttpClientHandlerTest.Cancellation.cs

feedback from review
42dde1d

runfoappBot mentioned this pull request Oct 30, 2020
System.Buffers.ArrayPool.Tests.CollectionTests.PollingEventFires failing in CI #44037
Closed

geoffkizer reviewed Nov 3, 2020
View reviewed changes

geoffkizer approved these changes Nov 3, 2020
View reviewed changes

wfurt merged commit 6ca1f20 into dotnet:masterNov 3, 2020

wfurt deleted the 100expect_41530 branch November 3, 2020 19:35

ghost locked as resolved and limited conversation to collaborators Dec 6, 2020

karelz added this to the 6.0.0 milestone Jan 26, 2021

improve accuracy of Expect100Continue_WaitsExpectedPeriodOfTimeBefore…
705d605
…SendingContent test

wfurt added area-System.Net.Http test-bug Problem in test source code (most likely) labels Oct 30, 2020

wfurt requested a review from a teamOctober 30, 2020 06:31

wfurt self-assigned this Oct 30, 2020

ManickaP approved these changes Oct 30, 2020
View reviewed changes

Comment threadsrc/libraries/System.Net.Http/tests/FunctionalTests/HttpClientHandlerTest.Cancellation.cs Outdated
Comment threadsrc/libraries/System.Net.Http/tests/FunctionalTests/HttpClientHandlerTest.Cancellation.cs

feedback from review
42dde1d

runfoappBot mentioned this pull request Oct 30, 2020
System.Buffers.ArrayPool.Tests.CollectionTests.PollingEventFires failing in CI #44037
Closed

geoffkizer reviewed Nov 3, 2020
View reviewed changes

geoffkizer approved these changes Nov 3, 2020
View reviewed changes

wfurt merged commit 6ca1f20 into dotnet:masterNov 3, 2020

wfurt deleted the 100expect_41530 branch November 3, 2020 19:35

ghost locked as resolved and limited conversation to collaborators Dec 6, 2020

karelz added this to the 6.0.0 milestone Jan 26, 2021

improve accuracy of Expect100Continue_WaitsExpectedPeriodOfTimeBefore…
705d605
…SendingContent test

wfurt added area-System.Net.Http test-bug Problem in test source code (most likely) labels Oct 30, 2020

wfurt requested a review from a teamOctober 30, 2020 06:31

wfurt self-assigned this Oct 30, 2020

ManickaP approved these changes Oct 30, 2020
View reviewed changes

Comment threadsrc/libraries/System.Net.Http/tests/FunctionalTests/HttpClientHandlerTest.Cancellation.cs Outdated
Comment threadsrc/libraries/System.Net.Http/tests/FunctionalTests/HttpClientHandlerTest.Cancellation.cs

feedback from review
42dde1d

runfoappBot mentioned this pull request Oct 30, 2020
System.Buffers.ArrayPool.Tests.CollectionTests.PollingEventFires failing in CI #44037
Closed

geoffkizer reviewed Nov 3, 2020
View reviewed changes

geoffkizer approved these changes Nov 3, 2020
View reviewed changes

wfurt merged commit 6ca1f20 into dotnet:masterNov 3, 2020

wfurt deleted the 100expect_41530 branch November 3, 2020 19:35

ghost locked as resolved and limited conversation to collaborators Dec 6, 2020

karelz added this to the 6.0.0 milestone Jan 26, 2021

Uh oh!

Conversation

wfurt commented Oct 30, 2020

Uh oh!

ghost commented Oct 30, 2020

Uh oh!

ManickaP left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

wfurt commented Oct 31, 2020

Uh oh!

azure-pipelinesBot commented Oct 31, 2020

Uh oh!

wfurt commented Nov 3, 2020

Uh oh!

wfurt commented Nov 3, 2020

Uh oh!

azure-pipelinesBot commented Nov 3, 2020

Uh oh!

geoffkizerNov 3, 2020

Choose a reason for hiding this comment

Uh oh!

geoffkizer left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

wfurt commented Oct 30, 2020

Uh oh!

ghost commented Oct 30, 2020

Uh oh!

ManickaP left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

wfurt commented Oct 31, 2020

Uh oh!

azure-pipelinesBot commented Oct 31, 2020

Uh oh!

wfurt commented Nov 3, 2020

Uh oh!

wfurt commented Nov 3, 2020

Uh oh!

azure-pipelinesBot commented Nov 3, 2020

Uh oh!

geoffkizerNov 3, 2020

Choose a reason for hiding this comment

Uh oh!

geoffkizer left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

wfurt commented Oct 30, 2020

Uh oh!

ghost commented Oct 30, 2020

Uh oh!

ManickaP left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!