ProtocolError: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response')) #1802
Comments
|
@eravion |
|
I'm going through the two mentioned issues as well as a general search on that error. Looking at the traceback in #4194 it looks to me as if the connection this error response is coming from is between selenium and webdriver. It interesting that you are seeing it on
|
|
Are you seeing this on one browser versus another? Are you primarily using/testing against one browser? |
|
Hello, We have the issue on both Firefox / Chrome. Some stats on the last 7 days, focus on 4 scenarios.
Stats on the last 7 days, focus on 2 other scenarios.
Answer to your question :
Not the same for a scenario. I think it is Random.
Not really. When it fail, sometime it is quick Sometime not For information, in any cases, the screenshot is ok, after the error message, I have a screenshot automatically done by the scenario. |
|
Some background on my question. You noted this does not occur with selenium 2.53 but does so with 4.x versions so I diff'd the py branch and in particular the remote_connection.py file (with,
There was, as expected, some changes there. I was tracing out some perceived differences in the headers and in how Chrome setup its headers. Thus the question about Chrome (and Firefox). But hearing your response and looking thorough that code that seems a bit of a dead end. And the Get Element Count I thought might be a time sink in that it could take a fair amount of time. Was curious as to whether or not they all took time and some just too much time. But your stats show it is a bit more random in the keywords and in the length of time it takes to fail. A few more questions ..
|
|
One more question .. are you able to run, maybe a subset of tests, without the grid? Just trying to eliminate where the issues might be coming from .. |
|
About Robot Framework 2.53: I added " Set Log Level TRACE" on Suite Setup on a scenario, let's wait for an error. I cannot run a test without grid. About selenium 4, we updated Python lib Same issue. |
|
20221025 13:59:10.836 - INFO - +-- START KEYWORD: SeleniumLibrary.Click Element [ xpath=//button[@Class='btn try-out__btn'] ] During handling of the above exception, another exception occurred: Traceback (most recent call last): |
|
I recall you mentioning the Screenshots on failure and raised the question whether this could be the problem. I don't think it is. There's a strange, to me at least, ordering with the screenshots and the last error. For some reason which I don't recall the screenshots appear before the last error log / traceback.. So it has always appeared to me that the screen shots occur before the for which they do not. That is just an artifact of the logging order. Now with that said I would be curious to see what happens in this case if you turn them off on library import with something like, *** Settings ***
Library SeleniumLibrary run_on_failure=NoneAgain I don't think this is the cause but I would think that it doesn't help trying to grab this fairly large request. What is noticeable in the TRACE level output is that there are two calls for the screenshot because the first one fails. Marking up that input I see So the screenshot also notices the dropped connection. Now I am not sure who is retrying that one and by what mechanism .. because looking into the traceback I see the element find also does a retry .. here, with it eventually in that traceback which on that response it fails when trying to read the response I'm curious as to these two different retries. In the screenshot one it seems to be a somewhat higher level method, guessing within selenium webdriver "protocols", to retry. Whereas the first (which appears second due to that odd logging order of screenshot before last error) seems a low level communication protocol / urllib retry. I do notice with the second screenshot webdriver call the session is still the same. I was wondering if the difference between the two is the screenshot retry is doing something in addition to just sending a webdriver call .. although i would expect to see that .. ??? One thing I might try in this situation given I could do this cleanly without breaking my build system is to patch selenium to turnoff connection manager's retries [code]. I have not tried this code but I was thinking something like !!! Caution !!! Again I warn you that this is not my system so be very careful if you do try this and know how to change it back if you do experiment with this. I don't expect this to totally fix this as I would think the connection would still break. Its just that low level retry would not occur. And what I would want it to do is the same as the screenshot in this example is successfully retry .. |
|
I disable screenshot, here is a trace : 20221026 06:59:05.578 - INFO - +-- START KEYWORD: SeleniumLibrary.Click Element [ xpath=//button[@Class='btn try-out__btn'] ] During handling of the above exception, another exception occurred: Traceback (most recent call last): |
|
That is pretty much what I had expected, no effect. If I get a chance, and it might not be today, I am curious as to how the screenshot request "recovers" from the dropped connection. From what I see these webdriver requests are retrying but failing. Also note that to me it does look like issue is on the selenium/grid/webdriver side. |
|
If there is some grid logging as well as browser side webdriver and/or browser logging, I would suggest diving into that too. There might be a clue in there. |
|
The trace while opening the session on the test and trace from the hub. 20221026 06:58:36.656 - DEBUG - Starting new HTTP connection (1): X.X.X.X:80 :~$ sudo docker logs selenium-hub | grep --color 9fd69a97-71ff-4d00-a8a5-2a5476e7762a I also added a timeout in the load of the lib : I'll check in the futur if it help or not and let you know. |
|
And we are using docker for node / hub. |
|
Could be .. I once had a server running some service virtualization tool. The servers and their setup and configuration were under a highly skilled team and I was just using the software. I started to have a problem that the virtualization would fail and on immediate retry pass. Then if left alone for a few minutes again fail on the first try and succeed every time afterwards till we were quiet for a while. Repeat. Turns out there was a load balancer in the middle which was shutting down and the service virtualization tool was not picking up the dropped connection/fixing it till my retry. From all I can see it looks like somewhere the communication channel from selenium through the grid to the webdriver. And from the logs it appears to be either grid or webdriver that initially drops the channel but selenium's retry fails. So grid is definitely in play as well as the docker instances that contain those parts. The drop channel could be from a crash (maybe unpreventable) or from some part of the communication chain breaking down. And there is some retry but that fails. So I would be examining in how the communication chain works and any logs from it. |
Hello,
I have an issue and open two ticket on Selenium and RobotFramework :
SeleniumHQ/selenium#10258
robotframework/robotframework#4194
Version installed :
Python 3.8
Version of Lib :
robotframework 4.1.2
robotframework-appiumlibrary 1.6.3
robotframework-pythonlibcore 3.0.0
robotframework-requests 0.9.2
robotframework-seleniumlibrary 5.1.3
selenium 4.1.0
Selenium grid hub and nodes Version 4.4.0
May I ask you to have a look please ?
The text was updated successfully, but these errors were encountered: