[browser][MT] System.Xml.Tests.TC_SchemaSet_Add_URL.v4

[simonrozsival]

The test internally calls the XmlDownloadManager which makes a GET HTTP request to http://bla/ and at that point the test execution gets stuck and eventually timeouts. I assume that this is caused by making a HTTP request on a non-browser thread but there might be something else going on.

Ref #74408

Stack:

-> using (Stream respStream = await client.GetStreamAsync(uri).ConfigureAwait(false))
-> return GetNonFileStreamAsync(uri, credentials, proxy).GetAwaiter().GetResult();
-> XmlDownloadManager.GetStream(absoluteUri, _credentials, _proxy);
-> stream = (Stream?)_laterInitParam.inputUriResolver.GetEntity(_laterInitParam.inputbaseUri, string.Empty, typeof(Stream));
-> FinishInitUriString();
-> XmlResolver tmpResolver = GetXmlResolver() ?? GetDefaultPermissiveResolver();
-> XmlReader reader = XmlReader.Create(schemaUri, _readerSettings);
-> sc.Add("xsdauthor", "http://Bla");

GetNonFileStreamAsync is called with a comment:

// This code should be changed if HttpClient ever gets real synchronous methods.  For now,
// we just use the asynchronous methods and block waiting for them to complete.

Expected exception form the hanging function: [out of order message from the browser]: http://bla/ - Failed to load resource: net::ERR_NAME_NOT_RESOLVED

[ghost]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

The test internally calls the XmlDownloadManager which makes a GET HTTP request to http://bla/ and at that point the test execution gets stuck and eventually timeouts. I assume that this is caused by making a HTTP request on a non-browser thread but there might be something else going on.

Author:	simonrozsival
Assignees:	-
Labels:	arch-wasm, area-Build-mono
Milestone:	8.0.0

[lewing]

@pavelsavara @lambdageek @kg this would be a good first issue for threaded js interop

[kg]

I wonder if unhandled exceptions in workers get forwarded to the console during tests?

[pavelsavara]

I wonder if unhanded exceptions in workers get forwarded to the console during tests?

We improved it here #74751

[pavelsavara]

@ilonatommy this is possibly working now, could you please test/enable ?

[ilonatommy]

It still hangs but ST works, I am changing the blocking condition in #94558

[ilonatommy]

The problem is this operation: .GetAwaiter().GetResult(), not HTTP request alone. When we make a HTTP request directly from the test (converted to async), it passes with the expected exception.

public async Task v4()
{
     try
     {
         var handler = new HttpClientHandler();
         string uri = "http://Bla";
         using (var client = new HttpClient(handler))
         {
              using (Stream respStream = await client.GetStreamAsync("http://Bla").ConfigureAwait(false)){} // Exception, correct!
         }
         XmlSchemaSet sc = new XmlSchemaSet();
         sc.Add("xsdauthor", "http://Bla");
     }
...

However, when we wrap the HTTP request in a helper async function and we use block-waiting for that function in the sync test, it hangs.

public void v4()
{
     try
     {
         AsyncHttpWrapper().GetAwaiter().GetResult(); // hangs
         XmlSchemaSet sc = new XmlSchemaSet();
         sc.Add("xsdauthor", "http://Bla");
     }
....

Theoretically, we could not use GetStream in MT but GetStreamAsync, I will see if that helps (it avoids block-waiting).

Edit: no, it does not help because eventually, in FinishInitUriString we are blocking the async calls anyway stream = (Stream)t.GetAwaiter().GetResult();

[pavelsavara]

I think GetResult() will (spin) block-wait the thread and the same threads needs event loop to resolve HTTP promise. This is nasty.