Opened 3 years ago

Last modified 2 years ago

#21227 new Bug

Selenium tests terminate with [Errno 10054]

Reported by: marfire Owned by: nobody
Component: Testing framework Version: master
Severity: Normal Keywords: selenium
Cc: apollo13 Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


When I run the test suite on Windows with the --selenium option, I consistently see errors like this:

Exception happened during processing of request from ('', 51603)
Traceback (most recent call last):
  File "C:\Program Other\Python27\Lib\", line 295, in _handle_request_noblock
    self.process_request(request, client_address)
  File "C:\Program Other\Python27\Lib\", line 321, in process_request
    self.finish_request(request, client_address)
  File "C:\Program Other\Python27\Lib\", line 334, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "C:\Django\django\django\core\servers\", line 126, in __init__
    super(WSGIRequestHandler, self).__init__(*args, **kwargs)
  File "C:\Program Other\Python27\Lib\", line 649, in __init__
  File "C:\Program Other\Python27\Lib\wsgiref\", line 116, in handle
    self.raw_requestline = self.rfile.readline()
  File "C:\Program Other\Python27\Lib\", line 447, in readline
    data = self._sock.recv(self._rbufsize)
error: [Errno 10054] An existing connection was forcibly closed by the remote host

Based on some anecdotal data, I tried putting a refresh() before the quit() in contrib.admin.tests.AdminSeleniumWebDriverTestCase._tearDownClassInternal() and that reliably solved the problem.

I have no idea why this works, but if it does it's probably worth doing since it should be harmless.

Attachments (1)

selenium_10054_aa1abb5f1e47e23a5aa9b56824c1e9bcf34e260d.patch (716 bytes) - added by tkhyn 3 years ago.

Download all attachments as: .zip

Change History (13)

comment:1 Changed 3 years ago by timo

  • Component changed from contrib.admin to Testing framework
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

There are some other places where we call selenium.quit() -- should those places be updated as well?

docs/topics/testing/overview.txt: cls.selenium.quit()
tests/view_tests/tests/ cls.selenium.quit()

comment:2 Changed 3 years ago by marfire

I think it's worth doing this wherever we're calling selenium.quit(), since it seems harmless and does solve the spurious failures. Here's a patch for it:

However, I hesitate to give this workaround canonical status by putting it in the documentation, since it's basically a bug in another project, could be fixed at any time, and adds a little extra noise and cognitive dissonance to the documentation. It only seems to pop up in some environments, and the workaround can be easily found with a quick internet search. On the other hand, for people developing reusable applications, it might be nice to warn them about this since it might affect them even if they aren't seeing the bug in their own test environments. Maybe the wiki is the right place for this?

comment:3 Changed 3 years ago by timo

  • Resolution set to fixed
  • Status changed from new to closed

In 08c9ab5a0f564a3ac7803e6a97fae855f2e0524e:

Fixed #21227 -- Added workaround for selenium test failures

Added a refresh() before quit() in the selenium tests, since this
solves the problem of spurious test failures in some environments.

comment:4 Changed 3 years ago by apollo13

@marfire That workaround slows down firefox pretty much and should Be unneeded; can you test if this sequence works better for you:

        if hasattr(cls, 'selenium'):
        super(AdminSeleniumWebDriverTestCase, cls)._tearDownClassInternal()
        if hasattr(cls, 'selenium'):

Last edited 3 years ago by apollo13 (previous) (diff)

comment:5 Changed 3 years ago by apollo13

@marfire: Is this a hard failure or just output on the console? Cause essentially everything which is a subclass of Exception is captured and more or less ignored.

comment:6 Changed 3 years ago by apollo13

  • Cc apollo13 added

comment:7 Changed 3 years ago by marfire

I'm out of town right now, but I'll try this next week and report back...

comment:8 Changed 3 years ago by Florian Apolloner <florian@…>

In 7d0a5190328f277b97b1f55171e1fecb22a1e461:

Revert "Fixed #21227 -- Added workaround for selenium test failures"

This reverts commit 08c9ab5a0f564a3ac7803e6a97fae855f2e0524e.

comment:9 Changed 3 years ago by apollo13

  • Resolution fixed deleted
  • Status changed from closed to new

I just reverted it since it doubles (or more) the time for firefox tests. The real fix should go something like this: When we tear down set a flag that we are in a shutdown process and then ignore the error.

comment:10 Changed 3 years ago by tkhyn


An attempt to mitigate this issue is in attached patch above.

The only way to make it work is to Attempt to set server_thread.httpd.ignore_errors = True before calling WebDriver.quit() in the Selenium test case class's tearDownClass, like that:

class MySeleniumTestCase(LiveServerTestCase)


    def tearDownClass(cls):
        if hasattr(cls, 'server_thread'):
            # test if server_thread attribute is available (as there may have been an exception in setUpClass)
            # setting ignore_errors flag on WSGI server thread to avoid unwanted 10054
            cls.server_thread.httpd.ignore_errors = True
        cls.wd.quit() # cls.wd is the WebDriver instance
        super(LiveServerTestCase, cls).tearDownClass()

Could not find a simpler way to do it as the flag must be set before calling wd.quit(). Fully integrating it in Django would require a django-specific SeleniumTestCase class on top of LiveServerTestCase.

Last edited 3 years ago by tkhyn (previous) (diff)

comment:11 Changed 2 years ago by timo

#22252 was a duplicate.

comment:12 Changed 2 years ago by anonymous

For anyone looking to repro this, here's a single test case that shows the error:

python --selenium admin_widgets.tests.DateTimePickerSeleniumFirefoxTests

be aware that if this PR on logging gets accepted ( then the error will no longer be visible on stdout. If I get time I'll try and build some kind of specific failing test for just this issue...

Note: See TracTickets for help on using tickets.
Back to Top