Test failure: Connect_Success

[aspnet-hello]

This test fails occasionally with the following error:

System.IO.IOException : Failed to bind to address http://127.0.0.1:54321: address already in use.
---- Microsoft.AspNetCore.Connections.AddressInUseException : Address already in use
-------- System.Net.Sockets.SocketException : Address already in use
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.BindEndpointAsync(ListenOptions endpoint, AddressBindContext context)
   at Microsoft.AspNetCore.Server.Kestrel.Core.LocalhostListenOptions.BindAsync(AddressBindContext context)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.AddressesStrategy.BindAsync(AddressBindContext context)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.BindAsync(IServerAddressesFeature addresses, KestrelServerOptions serverOptions, ILogger logger, Func`2 createBinding)
   at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServer.StartAsync[TContext](IHttpApplication`1 application, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Hosting.Internal.WebHost.StartAsync(CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Hosting.Internal.WebHost.Start()
   at Microsoft.AspNetCore.WebSockets.Test.KestrelWebSocketHelpers.CreateServer(ILoggerFactory loggerFactory, Func`2 app) in /_/test/Microsoft.AspNetCore.WebSockets.Test/KestrelWebSocketHelpers.cs:line 59
   at Microsoft.AspNetCore.WebSockets.Test.WebSocketMiddlewareTests.Connect_Success() in /_/test/Microsoft.AspNetCore.WebSockets.Test/WebSocketMiddlewareTests.cs:line 37
--- End of stack trace from previous location where exception was thrown ---
----- Inner Stack Trace -----
   at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.SocketTransport.BindAsync()
   at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServer.<>c__DisplayClass22_0`1.<<StartAsync>g__OnBind|0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.BindEndpointAsync(ListenOptions endpoint, AddressBindContext context)
----- Inner Stack Trace -----
   at System.Net.Sockets.Socket.UpdateStatusAfterSocketErrorAndThrowException(SocketError error, String callerName)
   at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress)
   at System.Net.Sockets.Socket.Bind(EndPoint localEP)
   at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.SocketTransport.BindAsync()
------- Stdout: -------
| [2018-08-21T03:03:44] TestLifetime Information: Starting test Connect_Success
| [2018-08-21T03:03:44] TestLifetime Information: Starting test Connect_Success
| [2018-08-21T03:03:44] Microsoft.AspNetCore.Server.Kestrel Critical: Unable to start Kestrel.
| System.IO.IOException: Failed to bind to address http://127.0.0.1:54321: address already in use. ---> Microsoft.AspNetCore.Connections.AddressInUseException: Address already in use ---> System.Net.Sockets.SocketException: Address already in use
|    at System.Net.Sockets.Socket.UpdateStatusAfterSocketErrorAndThrowException(SocketError error, String callerName)
|    at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress)
|    at System.Net.Sockets.Socket.Bind(EndPoint localEP)
|    at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.SocketTransport.BindAsync()
|    --- End of inner exception stack trace ---
|    at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.SocketTransport.BindAsync()
|    at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServer.<>c__DisplayClass22_0`1.<<StartAsync>g__OnBind|0>d.MoveNext()
| --- End of stack trace from previous location where exception was thrown ---
|    at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.BindEndpointAsync(ListenOptions endpoint, AddressBindContext context)
|    --- End of inner exception stack trace ---
|    at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.BindEndpointAsync(ListenOptions endpoint, AddressBindContext context)
|    at Microsoft.AspNetCore.Server.Kestrel.Core.LocalhostListenOptions.BindAsync(AddressBindContext context)
|    at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.AddressesStrategy.BindAsync(AddressBindContext context)
|    at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.BindAsync(IServerAddressesFeature addresses, KestrelServerOptions serverOptions, ILogger logger, Func`2 createBinding)
|    at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServer.StartAsync[TContext](IHttpApplication`1 application, CancellationToken cancellationToken)
| [2018-08-21T03:03:44] TestLifetime Information: Finished test Connect_Success in 0.0027189s

Other tests within that build may have failed with a similar message, but they are not listed here. Check the link above for more info.

This test failed on 2.1.

CC @Eilon (because the bot doesn't know who else to pick)

This issue was made automatically. If there is a problem contact ryanbrandenburg.

[aspnet-hello]

Please use this workflow to address this flaky test issue, including checking applicable checkboxes and filling in the applicable "TODO" entries:

• Is this actually a flaky test?

  • No, this is a regular test failure, fix the test/product (TODO: Link to commit/PR)
  • Yes, proceed below...

• Is this test failure caused by product code flakiness? (Either this product, or another product this test depends on.)

  • File a bug against the product (TODO: Link to other bug)
  • Is it possible to change the test to avoid the flakiness?
    • Yes? Go to the "Change the test!" section.
    • No?
      • Disable the test (TODO: Link to PR/commit)
      • Wait for other bug to be resolved
      • Wait for us to get build that has the fix
      • Re-enable our test (TODO: Link to PR/commit)
      • Close this bug

• Is it that the test itself is flaky? This includes external transient problems (e.g. remote server problems, file system race condition, etc.)

  • Is there is a way to change our test to avoid this flakiness?
    • Yes? Change the test!
      • Change the test to avoid the flakiness, for example by using a different test strategy, or by adding retries w/ timeouts (TODO: Link to PR/commit)
      • Run the test 100 times locally as a sanity check.
      • Close this bug
    • No?
      • Is there any logging or extra information that we could add to make this more diagnosable when it happens again?
        • Yes?
          • Add the logging (TODO: Link to PR/commit)
        • No?
          • Delete the test because flaky tests are not useful (TODO: Link to PR/commit)

This comment was made automatically. If there is a problem contact ryanbrandenburg.

[ryanbrandenburg]

This belongs on the home repo.