Open tuxayo opened 10 months ago
The error handler has no inherent protections against the handler itself exploding.
Perhaps I should build some in? Wrapping it with an eval { ... } or do { ... } block should do the trick.
The error handler has no inherent protections against the handler itself exploding. Perhaps I should build some in? Wrapping it with an eval { ... } or do { ... } block should do the trick.
Maybe adding that might also help getting output of the error that made the handler explode :)
I hope at least. For that screenshot thing, it's very weird, that only happens on my PC that runs the same containers as the CI. For which I haven't heard about builds getting stuck until timeout and filling the storage with millions of lines of stacktraces ^^" (really, that super fast, a few minutes is already hundreds of MB)
In a project there is an error handler [1] added to take a screenshot on test failure.
At some point in a test, there is a find_element that fails and the handler is called. And then taking a screenshots fails. (so the handler is called over and over but the lack of try catch (wait, that might not even help) to prevent that is not the current issue)
Is there a way to know more about from where the error comes from? I even tried to mess with that place https://github.com/teodesian/Selenium-Remote-Driver/blob/1f078d8f41ae02cbeb51d0a6ad460c0aee6c98fc/lib/Selenium/Remote/Driver.pm#L848 and replace the call to the error handler (that will result in an endless recursion) with just a
croak $_;
but I 'm not sure that's the right variable where there is a chance to find the error that was returned by the rest of Selenium::Remote::Driver or selenium or the browser.Selenium::Remote::Driver: 1.47 Selenium: 3.141.59 Firefox: 92 (last version compatible with selenium 3 it seems) Output of the error: [2]
[1]
[2]