Showing stack traces on KeyboardInterrupt

[asmeurer]

Right now, the default behavior of pytest when you keyboard interrupt it is to hide the traceback, and print a message saying that you can show it with --full-trace.

I would like to suggest that it should instead always show the full traceback by default. Sometimes a test will randomly get stuck in an infinite loop. My only hope of debugging it is if I interrupt and see a traceback. I can't always rely on being able to reproduce it, so I can't just "rerun the test with --full-trace". The best I can do is to put --full-trace in my pytest.ini as a flag that is always enabled, but

• I have to do this for every project (and can't really for those I don't control)
• --full-trace also makes tracebacks extremely verbose even for normal test failures. So this is the price I have to pay to be able to see tracebacks.

I would suggest that at the very least, keyboard interrupts should have their own dedicated flag, instead of only being controlled by --full-trace. And I would highly suggest that the default of that flag should be to show the tracebacks, not to hide them, so that the user has to opt out of seeing them (not that I particularly understand why you would ever want to do that).

[iwanb]

I concur that having a traceback on KeyboardInterrupt by default would be handy, as typically you see that your test is stuck for too long, you type Ctrl+C and have nothing to debug further. It could be a reduced traceback if we want to avoid cluttering the output.

[bluetech]

And I would highly suggest that the default of that flag should be to show the tracebacks

I am -1 on this particular point. I think in the majority of cases the Ctrl-C is used to just stop pytest once the relevant information has been gleaned, not to debug a particular test.

As for the other suggestions, maybe we can do them, depends on the details. Best would be to avoid a flag, pytest already has enough of those!

BTW, what I usually do in these cases is re-run the testsuite with pytest --pdb, then a Ctrl-C drops me in a pdb shell and I can the stacktrace, variables etc of the problematic test.

[The-Compiler]

FWIW to debug hanging tests, you can also set e.g. faulthandler_timeout = 30 in the config, which will show you a stacktrace when a test hangs for more than 30 seconds.

[asmeurer]

I am -1 on this particular point. I think in the majority of cases the Ctrl-C is used to just stop pytest once the relevant information has been gleaned, not to debug a particular test.

But I don't understand what the problem is with showing the traceback, even if you aren't interested in seeing it. If it's there but you don't want to see it, that's not a big deal, but if it's hidden but you wanted to see it, it is a problem. And already when you Control-C it shows the failures up to that point, so it's not like interrupting the tests is a clean operation in terms of not printing stuff to the terminal.

BTW, what I usually do in these cases is re-run the testsuite with pytest --pdb, then a Ctrl-C drops me in a pdb shell and I can the stacktrace, variables etc of the problematic test.

Or you can re-run with --full-trace. But the point is that sometimes rerunning doesn't even work, if it is a flaky hang. Or sometimes it would take a long time to get to the hanging test again.

[bluetech]

But I don't understand what the problem is with showing the traceback, even if you aren't interested in seeing it.

Showing tracebacks is not really great UI, they are long, cryptic and annoying, and in the case of Ctrl-C are irrelevant most of the time.

---

Overall, I am -1 on changing Ctrl-C to output stacktrace by default, and -0 on making this configurable (e.g.--full-trace=ctrlc or such; --full-trace does seem to control a few unrelated things...).

[nicoddemus]

Showing tracebacks is not really great UI, they are long, cryptic and annoying, and in the case of Ctrl-C are irrelevant most of the time.

I agree.

While I understand and sympathize that stuck tests is a frustrating problem, making the UI worse for every user by default is not ideal.

I also don't like adding a new flag for this, but changing --full-trace from a bool (--full-trace=True/False) to an enumerated flag (--full-trace=no,all,ctrlc) is a possibility.

Another possibility is to add an environment variable to control this, if we assume this is niche and probably set environment wide.

---

Another suggestion is to use pytest-timeout, which will stop the test and show a traceback after X seconds, similar to the fault handler option.

[asmeurer]

Showing tracebacks is not really great UI,

This the same thing that the default Python interpreter does. For end user tools, where tracebacks are meaningless, hiding them can be useful (i.e., many command line utilities written in Python do this). But pytest is a developer tool. Tracebacks are directly helpful to the people using it.

they are long,

They are only long because you have to enable them with a flag that makes stack traces ridiculously long. And even if you consider the normal pytest tracebacks too long (FWIW I wouldn't), that is pytest's fault. A normal Python traceback usually fits in a single fullscreen terminal window in practice, and rarely takes up more than two.

cryptic...in the case of Ctrl-C are irrelevant most of the time.

If I'm running my tests for my code, the traceback shows is the trace for my code. How is that cryptic or irrelevant? I agree that showing the pytest parts of the traceback is not helpful to most people, and I'm not opposed to hiding that by default (just as is done with failures).

and annoying

... making the UI worse for every user by default

I really can't understand why you would write stuff like this. I'm a user of pytest. I find its behavior of not showing tracebacks annoying. Why would you say "making the UI worse for every user" when there's clearly a user, me, for whom changing this would make things better, not worse. Why can't you just argue the merits of this in its own right, without trying to erase people who disagree with you (including the very person who opened the issue!)? I still haven't really seen an argument for this behavior that isn't just "it's bad", which not only isn't really an argument, it directly contracts reality (see what I wrote above).

I didn't just open this issue for theoretical purposes. This is something that annoys me literally every single day. Either I annoyingly have to rerun my tests every time I need to interrupt them with the --full-trace flag, and hope the hang is actually reproducible, or I make --full-trace the default and live life with obnoxiously large tracebacks from every test failure.

Another possibility is to add an environment variable to control this, if we assume this is niche and probably set environment wide.

I do want this behavior everywhere in every project, so this makes more sense to me. Although I still maintain that showing should be default. IMO hiding should be the niche thing and I personally don't even see why there should be an option for it (but if people want it, I don't oppose adding it).

Another suggestion is to use pytest-timeout, which will stop the test and show a traceback after X seconds, similar to the fault handler option.

That's not really the same as control-c. You either have to do it ahead of time (which is no better than the current remembering to include --full-trace situation), or try to come up with a timeout that is both short enough to not require too much waiting but long enough to not have false positives.

[The-Compiler]

FWIW I'm also opposed to showing a full traceback by default. I'm pretty sure people use ctrl-c to interrupt pytest to see the results (or just because they forgot some option) much more than they use ctrl-c to debug a hanging test. I'd rather optimize for the common case, especially if there are various alternative solutions available for yours.

Having a --full-trace=ctrlc is certainly an option, I agree --full-trace is doing various different things at once.

I suppose another option would be to make the KeyboardInterrupt traceback a bit more clever by default:

• If we're inside pytest internals, don't show a trace (like now)
• If we're inside a test, show the --tb=short format of the part inside the test (like if there were a failure in that test with --tb-short).

I suppose in most testsuites, the latter would still display a very manageable stacktrace without being too cryptic/annoying - as it's likely just going to be a handful of frames with (I think?) 2 lines each.

[nicoddemus]

I really can't understand why you would write stuff like this. I'm a user of pytest. I find its behavior of not showing tracebacks annoying. Why would you say "making the UI worse for every user" when there's clearly a user, me, for whom changing this would make things better, not worse.

Sorry, didn't mean to be dismissive of your problem, I meant that for most users it would be a bit annoying.

I think @The-Compiler's proposal is a good compromise: show a short traceback, hiding the pytest internals. Seems to me this is a good enough UX, most users won't really bother seeing a small traceback when hitting KeyboardInterrupt. This also doesn't need a new option. 👍 from me on that.

[asmeurer]

If I understand the proposal correctly, that would solve my problem.