What test was running during a signal trap?

[devinburnette]

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..

[ArturT]

The spec file could be in the main thread backtrace as shown here:
https://docs.knapsackpro.com/ruby/troubleshooting/#why-does-the-ci-node-hang-backtrace-debugging

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.

[devinburnette]

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.

[ArturT]

We release the knapsack_pro 7.14.0 version.

It shows paths to spec files and line numbers running when the node was hanging and terminated.

We also show the RSpec command, including seed, so you can copy & paste it locally to reproduce the last batch of tests fetched from the Queue API.

Docs have been updated.
https://docs.knapsackpro.com/ruby/troubleshooting/#why-does-the-ci-node-hang-backtrace-debugging