Skip to content

Conversation

@mandel-macaque
Copy link
Contributor

If we are getting errors (500,401..) do not mark a link all test as a
failure, but as inconclusive.

Fixes: https://github.com/xamarin/maccore/issues/2056

If we are getting errors (500,401..) do not mark a link all test as a
failure, but as inconclusive.

Fixes: https://github.com/xamarin/maccore/issues/2056
@monojenkins
Copy link
Collaborator

Build failure
Build succeeded
API Diff (from stable)
API Diff (from PR only) (no change)
Generator Diff (no change)
🔥 Test run failed 🔥

Test results

16 tests failed, 70 tests passed.

Failed tests

  • monotouch-test/watchOS 32-bits - simulator/Debug: Crashed
  • framework-test/watchOS 32-bits - simulator/Debug: Crashed
  • interdependent-binding-projects/watchOS 32-bits - simulator/Debug: Crashed
  • fsharp/watchOS 32-bits - simulator/Debug: Crashed
  • introspection/watchOS 32-bits - simulator/Debug: Crashed
  • dont link/watchOS 32-bits - simulator/Debug: Crashed
  • dont link/watchOS 32-bits - simulator/Release: Crashed
  • link all/watchOS 32-bits - simulator/Debug: Crashed
  • link all/watchOS 32-bits - simulator/Release: Crashed
  • link sdk/watchOS 32-bits - simulator/Debug: Crashed
  • link sdk/watchOS 32-bits - simulator/Release: Crashed
  • mono-native-compat/watchOS 32-bits - simulator/Debug: Crashed
  • mono-native-unified/watchOS 32-bits - simulator/Debug: Crashed
  • monotouch-test/watchOS 32-bits - simulator/Debug (LinkSdk): Crashed
  • monotouch-test/watchOS 32-bits - simulator/Debug (static registrar): Crashed
  • monotouch-test/watchOS 32-bits - simulator/Release (all optimizations): Crashed

@mandel-macaque
Copy link
Contributor Author

} else {
string content = await response.Content.ReadAsStringAsync ();
waited = true;
bool success = !String.IsNullOrEmpty (content);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tiny nit: it's a little confusing to have a whole bool success variable that we expect to be true always.

In the context of http request code, I would expect a variable named success to indicate something like response.IsSuccessStatusCode, but it seems like by the time we hit the else branch we're already in the success case :)

Otherwise, looks good to me.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good point. I think we are just testing that async/await works. If that is the case, even the errno would be good.

@rolfbjarne do you know why do we have this tests exactly? I looked at the bugzilla issue and might just be for the async support.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test was added here: https://github.com/xamarin/maccore/commit/ca7dd9294d173893fbb2b635175141797261ead8, and yes, it looks like it was just to make sure async/await works.

But did you try just changing the url to http://example.com? That's a url we're already using in other places, and which will fail if the url goes down. It's possible http://msdn.microsoft.com will always return us a 500 code, and it doesn't feel right to ignore any such failures (eventually we'll end up ignoring legitimate failures).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

make sense to reduce the number of endpoint our tests depends on... maybe we should have them as constants (in a different PR)

} else {
string content = await response.Content.ReadAsStringAsync ();
waited = true;
bool success = !String.IsNullOrEmpty (content);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

make sense to reduce the number of endpoint our tests depends on... maybe we should have them as constants (in a different PR)

@mandel-macaque
Copy link
Contributor Author

@spouliot @rolfbjarne I'll update the url, seems like msd is giving a lot of problems. Ignoring anyway seems good, since inconclusive in this case is what we want. BUT! Maybe just the HttpResponse with the errno is good enough to test the async pattern, and in this particular case we do not care about the content of the response.

@monojenkins
Copy link
Collaborator

Build success
Build succeeded
API Diff (from stable)
API Diff (from PR only) (no change)
Generator Diff (no change)
Test run succeeded

@mandel-macaque mandel-macaque merged commit ca98880 into dotnet:master Nov 12, 2019
@mandel-macaque
Copy link
Contributor Author

@monojenkins backport xcode11.2

@mandel-macaque
Copy link
Contributor Author

@monojenkins backport xcode11.3

@mandel-macaque
Copy link
Contributor Author

@monojenkins backport d16-5

@mandel-macaque
Copy link
Contributor Author

@monojenkins backport d16-4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants