[HTTP/3] Fixed stress

[ManickaP]

The artifact pulling in msquic has been deleted from AzDO --> pulled newer msquic.
Remove exclusion of 100-continue scenario from H/3, which should now be fixed in the base image.

[ghost]

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

Issue Details

---

The artifact pulling in msquic has been deleted from AzDO --> pulled newer msquic.
Remove exclusion of 100-continue scenario from H/3, which should now be fixed in the base image.

Author:	ManickaP
Assignees:	-
Labels:	area-System.Net.Http
Milestone:	-

[ManickaP]

/azp run runtime-libraries stress-http

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[ManickaP]

@antonfirsov the docker build is still broken, in Windows (it fails) and in Linux as well (doesn't fail, but runs I don't know what). The problem is that the images contain 6.0 SDK and runtime and we copy over 7.0 testhost (runtime) into 6.0 directory -> which is incompatible.

7.0 docker images do not exists yet. We can wait for them, or we can install 7.0 SDK within 6.0 docker images. I tried to do that but I hit one problem after another, so I'm giving up (I already gave this 2+ days).

So I'd love to get this in and solve the other issues separately.

EDIT: I can revert all the "pull newest image" changes, that was my first attempt to fix this, but it doesn't help (nor it hurts).

[antonfirsov]

@ManickaP wow, this is bad. I will also look into the issue tomorrow.

we can install 7.0 SDK within 6.0 docker images

I'm not sure if I understand the full extent of the problem, but AFAIK this is how this worked before. Do you know when/how did this got broken?

[ManickaP]

I'm not sure if I understand the full extent of the problem, but AFAIK this is how this worked before. Do you know when/how did this got broken?

Doesn't seem like it, we were using an existing docker image with .NET (Core) SDK and runtime preinstalled. Then we build runtime repository and copy 'testhost' binaries over the pre-installed runtime inside the image. And this is currently problem since the image contains 6.0 bits but runtime main is 7.0.

In order to make this work, we could install 7.0 SDK and runtime manually in the image via https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-install-script (there already is 7.0 main build available: https://github.com/dotnet/installer), move the stress to target 7.0 and copy the 'testhost' over 7.0 (ignoring 6.0 SDK). That should work, but it means getting the script and invoking it within the docker image.

[antonfirsov]

msquic changes look good, but there are some unrelated ones, I'd like to understand the purpose.

Is it that we need to get this fix in despite stress being completely broken on main, so we can propagate the fix to the servicing branches? Shouldn't we also backport #59410 then?

[ManickaP]

As I said in the older comment:

EDIT: I can revert all the "pull newest image" changes, that was my first attempt to fix this, but it doesn't help (nor it hurts).

In another words, the only change that matters is the one with msquic, the rest are my feeble attempts to fix the complete brokenness of the stress test and I can revert them.

[ManickaP]

In the end, I removed all the image pulling experiments to keep the PR saner. I also removed the remnant of that from SslStress/run-docker-compose.sh which was a left over from my previous experiments.

@antonfirsov it should be now much less 'controversial' 😄

[ManickaP]

/azp run runtime-libraries stress-http

[ManickaP]

/azp run runtime-libraries stress-ssl

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[antonfirsov]

Thanks! Sorry for being overly worried about the other changes. It's pure pain to make stress work again, any change we can't validate on the CI makes me more anxious now.

[antonfirsov]

/backport to release/6.0

[github-actions]

Started backporting to release/6.0: https://github.com/dotnet/runtime/actions/runs/1364358871

[github-actions]

@antonfirsov backporting to release/6.0 failed, the patch most likely resulted in conflicts:

$ git am --3way --ignore-whitespace --keep-non-patch changes.patch

Applying: Fixed stress
Using index info to reconstruct a base tree...
M	eng/pipelines/libraries/stress/http.yml
M	src/libraries/System.Net.Http/tests/StressTests/HttpStress/Dockerfile
Falling back to patching base and 3-way merge...
Auto-merging src/libraries/System.Net.Http/tests/StressTests/HttpStress/Dockerfile
CONFLICT (content): Merge conflict in src/libraries/System.Net.Http/tests/StressTests/HttpStress/Dockerfile
Auto-merging eng/pipelines/libraries/stress/http.yml
CONFLICT (content): Merge conflict in eng/pipelines/libraries/stress/http.yml
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 Fixed stress
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!