You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now we get the backtrace of all the threads when trapping a signal from a timeout for example, but it's still difficult to pin point which test the calls are coming from..
Is there a way to output the test or tests that were running at the time of the signal trap? We get the "retry the previous batch of tests" in the INFO logs, but not for the current batch of tests..
The text was updated successfully, but these errors were encountered:
If not, then something else could freeze, like factories (FactoryBot) etc.
You may also see the name of the test case in the output right before the thread backtraces if you use rspec --format documentation. It's easier to catch the problematic test case then.
Feel free to share the full txt output from a node that hangs to the support email https://knapsackpro.com/contact
We can analyze it. Perhaps there is a better way to narrow down the root issue or automate it somehow so the output is more readable.
It may be helpful to include the seed in the debug logs BEFORE a batch of tests are executed, in the case of a signal trap due to timeout, we never get to see the seed and it makes it difficult to try to reproduce the issue locally.
Right now we get the backtrace of all the threads when trapping a signal from a timeout for example, but it's still difficult to pin point which test the calls are coming from..
Is there a way to output the test or tests that were running at the time of the signal trap? We get the "retry the previous batch of tests" in the INFO logs, but not for the current batch of tests..
The text was updated successfully, but these errors were encountered: