Raise a more specific error if the websocket connection dies #86
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We're having an issue in our CI environment where our container is sporadically timing out, and we think it may be because the Chrome client is dying silently or disconnecting, and Apparition is not realizing it.
I'm able to reproduce the issue of Apparition hanging locally by starting some specs in one terminal window, and
kill
ing the Chrome process that is spawned via another terminal window usingkillall -m Chrome
(careful if you are actually using Chrome at the time). Killing Chrome causes apparition to hang permanently - the only way to get the specs to stop is Ctrl+C (twice).After looking into why that happens, I thought this issue might hold the answer faye/websocket-driver-ruby#61 . Apparently, it's possible that the Websocket Driver's connection fails without firing the
:close
event. In addition to listening for that event, we should also check the return value of#read
and ensure it's notnil
or an empty string.Well, I tried just checking for
nil
and""
, and it didn't seem to work. I was able to verify that thesocket.read
call was where apparition was hanging, and it seems thereadpartial
call is blocking, so I replaced it withread_nonblock
. That method is, according to the docs, the exact same other than the blocking flag. Once I used the non-blocking form ofread
, and raised an error when the timeout occurs, I see the expected error output, but apparition continues to hang 😞 . This happens _even if I set theabort_on_exception
flag to true on the@listener
thread. 😕 I have no idea why.I'm hoping you can help me build on this PR to properly address this issue.