Crashes on 0.71.0 when pushing/popping screens quickly about textual HOT 8 OPEN

I'm not sure the deadlock detection is hiding an error. Without the timeout, it would have frozen.

If a broken compose prevents a mount or prune, we might have to handle that case explicitly.

from textual.

It was definitely hiding an error (to be clear, I mean an error in my app, not Textual, inside a widget's compose method. By "hiding", I mean there was no stack trace printed by Textual anywhere indicating why my app crashed, just the TimeoutError) - I wrapped the code that contained an exception in a try/except and printed out the exception.

When I didn't catch the error myself, it bubbled up to Textual and the app crashed with the deadlock issue after 5 seconds, and there was no sign of the original error.

from textual.

I will try to MRE this tomorrow.

from textual.

Have spent some time trying and failing to MRE this, but I'm pretty certain there's an issue.

My app had a logic bug which caused a plain old exception to be raised, but Textual never presented that exception to the user. The user was only presented with "possible deadlock" when the app crashed.

from textual.

I just hit this issue again - receiving a "possible deadlock" which is hiding another exception in my app, making debugging difficult.

I think it's unrelated to screens and is a more general issue - trying another MRE now.

from textual.

Override _handle_exception in the App:

E.g.:

    def _handle_exception(self, error: Exception) -> None:
        global exc
        exc = error
        super()._handle_exception(error)

It'll allow you to see the errors

from textual.

I've also noticed that I get this warning in the devtools each time I see the deadlock issue:

[14:45:01] WARNING                                            _callback.py:73
Callback functools.partial(<function
Footer.on_mount.<locals>.bindings_changed at 0x1047f87c0>, MainScreen()) is
still pending after 3 seconds

from textual.

Seems to not be restricted to 0.71.0.

@arcivanov The issue here is exceptions are not making it into Textual's usual error handling flow, so this doesn't do anything in this case.

from textual.