Currently any unhanded exceptions will result as Internal Server Error. When the traceback happens we'll get it in the logs, but the response is typically just a "Internal Server Error" with status code 500. starlette has an option to also include the traceback in the response, which can be very helpful specially on e2e when isolating issues, that way even without correlating with the log you can still get a nice traceback if the client also include response.text in the assertion, that way also facilitating collecting evidences for bug reports. So, having an option something like api_debug_traceback = True or something similar would be great. This mode doesn't have any major performance penalty, so it'll be True by default. Exposing a traceback on a 500 in most cases for an open source project there's virtually no risk.
Currently any unhanded exceptions will result as Internal Server Error. When the traceback happens we'll get it in the logs, but the response is typically just a "Internal Server Error" with status code 500.
starlette
has an option to also include the traceback in the response, which can be very helpful specially on e2e when isolating issues, that way even without correlating with the log you can still get a nice traceback if the client also includeresponse.text
in the assertion, that way also facilitating collecting evidences for bug reports. So, having an option something likeapi_debug_traceback = True
or something similar would be great. This mode doesn't have any major performance penalty, so it'll be True by default. Exposing a traceback on a 500 in most cases for an open source project there's virtually no risk.