Remove the HTTP2 and HTTP3 implementations on browser-wasm.

[eerhardt]

This allows for HPackEncoder and QPackEncoder to be trimmed in browser wasm.

Contributes to #44534

.br size of dotnet new blazorwasm app:

• Before: 2,645,237 bytes
• After: 2,644,568 bytes

[ghost]

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

Issue Details

---

This allows for HPackEncoder and QPackEncoder to be trimmed in browser wasm.

Contributes to #44534

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

[JamesNK]

Some of this code is shared with aspnetcore. Will the changes require a reaction in aspnetcore?

[eerhardt]

Will the changes require a reaction in aspnetcore?

I think the only change would be to include the new files in whatever .csproj uses them. For example: H2StaticTable.Http2.cs

[eerhardt]

@dotnet/dnceng - can anyone tell what the problem was with the Linux x64 Debug leg? From the log:

https://helixre8s23ayyeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-pull-52420-merge-37c8355645b34b3898/System.Text.Json.Tests/console.61dff846.log?sv=2019-07-07&se=2021-05-27T02%3A08%3A38Z&sr=c&sp=rl&sig=MyyNTiEGD%2Fqdqb8jCRrP72JzAP6Cmamkb%2BD%2FfQLy%2FIg%3D

Searching '/datadisks/disk1/work/9C56086D/w/B9180A1C/e' for test results files
Found results file /datadisks/disk1/work/9C56086D/w/B9180A1C/e/testResults.xml with format xunit
Searching '/datadisks/disk1/work/9C56086D/w/B9180A1C/uploads' for test results files
Worker 6: uploaded 1000 results
Worker 4: uploaded 1000 results
Worker 8: uploaded 1000 results
Worker 9: uploaded 1000 results
Worker 1: uploaded 1000 results
Worker 7: uploaded 1000 results
Worker 2: uploaded 1000 results
Worker 0: uploaded 1000 results
Worker 8: uploaded 2000 results
Worker 3: uploaded 1000 results
Worker 6: uploaded 2000 results
Worker 4: uploaded 2000 results
Worker 9: uploaded 2000 results
Worker 1: uploaded 2000 results
Worker 0: uploaded 2000 results
Worker 7: uploaded 2000 results
Worker 2: uploaded 2000 results
Worker 8: uploaded 2980 results
Worker 5: got error: Traceback (most recent call last):
  File "/datadisks/disk1/work/9C56086D/p/reporter/run.py", line 44, in run
    self.__process(item)
  File "/datadisks/disk1/work/9C56086D/p/reporter/run.py", line 34, in __process
    self.publisher.upload_batch(batch)
  File "/datadisks/disk1/work/9C56086D/p/reporter/azure_devops_result_publisher.py", line 35, in upload_batch
    self.publish_results(test_case_results, test_name_order, results_with_attachments)
  File "/datadisks/disk1/work/9C56086D/p/reporter/azure_devops_result_publisher.py", line 70, in publish_results
    published_results = test_client.add_test_results_to_test_run(list(test_case_results), self.team_project, self.test_run_id)  # type: List[TestCaseResult]
  File "/home/helixbot/.azdo-env/lib/python3.6/site-packages/azure/devops/v5_1/test/test_client.py", line 679, in add_test_results_to_test_run
    content=content)
  File "/home/helixbot/.azdo-env/lib/python3.6/site-packages/azure/devops/client.py", line 104, in _send
    response = self._send_request(request=request, headers=headers, content=content, media_type=media_type)
  File "/home/helixbot/.azdo-env/lib/python3.6/site-packages/azure/devops/client.py", line 68, in _send_request
    self._handle_error(request, response)
  File "/home/helixbot/.azdo-env/lib/python3.6/site-packages/azure/devops/client.py", line 272, in _handle_error
    status_code=response.status_code))
azure.devops.exceptions.AzureDevOpsClientRequestError: Operation returned an invalid status code of 503.

2021-05-07 02:39:59,300: INFO: 140378837313344: run(114): main: Main thread exiting
+ export _uploaderExitCode=57
+ date -u +%FT%TZ
2021-05-07T02:39:59Z
+ export PYTHONPATH=/usr/bin/python3:/etc/helix/scripts
+ exit 57
+ exit 57

[MattGal]

@dotnet/dnceng - can anyone tell what the problem was with the Linux x64 Debug leg? From the log:

azure.devops.exceptions.AzureDevOpsClientRequestError: Operation returned an invalid status code of 503.

2021-05-07 02:39:59,300: INFO: 140378837313344: run(114): main: Main thread exiting

• export _uploaderExitCode=57

Sure, I can talk to this. You've now taken the changes from dotnet/arcade#7310 , which means that when test results can't be reported to Azure Devops, the work item fails. The HTTP 503 would, prior to this change, have resulted in incomplete or non-reporting to AzDO , while leaving the work item's exit code as 0 (Since we now coerce both 1 (failed some tests) and 0 (passed all tests) to 0).

Previously, we were suppressing this problem; when it happens, it enables a change that breaks a test, if it gets lucky while Azure DevOps is having a bad day, to "pass". This came because before, we'd exit with the same exit code XUnit did when tests failed, but once it was decided by folks that we would turn all the 1s to 0s, this became necessary to prevent ignoring failure. My preference would be to not coerce the exit codes, but there was some reason this particular behavior was needed for the developer workflow.

This is, hopefully, a point-in-time issue; @ChadNedzlek is working on stuff that will put the reporting into the Helix client and remove the need to do it inside the work item, allowing greater control over retry logic and handling of the problem.

[eerhardt]

Thanks for the explanation @MattGal. So in summary - we can treat these failures as "flaky infrastructure"?

[MattGal]

Thanks for the explanation @MattGal. So in summary - we can treat these failures as "flaky infrastructure"?

Sure, as long as we're counting this particular flakiness as ADO's :)