Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add breakpoint middleware #2893

Closed
wants to merge 1 commit into from
Closed

add breakpoint middleware #2893

wants to merge 1 commit into from

Conversation

davidism
Copy link
Member

@davidism davidism commented May 3, 2024

The interactive debugger is a constant source of (usually invalid) security reports. Nowadays, there are a lot of nice Python debuggers besides the built-in pdb. Python has a built-in breakpoint() function which will start the user's preferred debugger. For example, pudb, ipdb, pdbpp, or IDE debuggers such as PyCharm and VSCode. This middleware catches unhandled exceptions, finishes the response, then calls breakpoint() to allow the user to inspect the stack. This provides exactly as much information as the interactive debugger, but without the huge complexity of storing frames, threads, contexts, etc or serving a remote Python interpreter UI.

@davidism
Copy link
Member Author

davidism commented May 3, 2024

For example, pip install pudb, then run a Flask application with PYTHONBREAKPOINT=pudb.set_trace flask run --debug. On an unhandled exception, the browser displays a standard 500 error page, and the nice PUDB UI is displayed in the terminal. PyCharm sets this for you, so if you start a Flask app with the debug button, an unhandled exception will activate the debug panel frame inspector.

@davidism
Copy link
Member Author

davidism commented May 3, 2024

I deliberately named this WSGIMiddleware, since I think an ASGIMiddleware could easily be written as well, I just don't know quite enough about how ASGI handles errors to do that.

@davidism
Copy link
Member Author

davidism commented May 3, 2024

One thing I failed to account for is that breakpoint() doesn't deal with post-mortem debugging. Calling breakpoint() stops where it's called in the except block, which is after the function that raised it has exited (due to raising an exception). We want to debug the traceback that we caught, not the current state. Most debuggers do have a separate post_mortem() call instead of set_trace(), but it's not guaranteed, and we'd need some way to detect the debugger and then find its post mortem call instead.

@davidism davidism closed this May 4, 2024
@davidism davidism deleted the breakpoint branch May 4, 2024 16:46
@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 19, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant