-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Improve Tracebacks for narrow terminals #1939
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
Conversation
|
There's a configuration for rich tracebacks that I use in another project that I've found is nice, basically limiting to 3 levels for the traceback and excluding FastMCP and mcp modules from the tracebacks. I'm fine with just disabling outright but we could try just making them less bad first? |
|
Something like |
|
Oh interesting, I wasn't aware -- happy to do that. I think the main reason for the dislike is that when they are narrow they are totally unusable (which I think you're wrestling with elsewhere for console width) |
|
I was planning on looking at console width tomorrow and will let you know if I find anything |
|
I made a quick project and deployed it to FastMCP cloud https://github.com/strawgate/py-mcp-terminal-size And didn't discover anything revealing Will play with it more today |
|
Basically I think what's happening is Rich sees the console as 80 characters wide It's a little misleading because fastmcp.cloud is stripping whitespace from the log line -- but here's what the actual layout really looks like (with a much wider width): The timestamp (which is blank if it's the same as the last one) plus LEVEL plus File plus Line Number leaves ~30 characters for the traceback if the console is limited to 80 characters wide. |
|
Using a specific handler for tracebacks where we don't include the error level or file path gives a lot more room for the traceback. |
|
@jlowin i can implement this if you want otherwise we can proceed with whatever you think is best |
|
Rich has an option to wrap the code lines, but it's off by default. We could enable it, but truncated has been fine for me. This is the worst-case scenario, though, where the terminal is not dynamic and is limited to exactly 80 chars. As long as it shows enough code to point to the section that's causing the problem that's a big improvement. With the limit of 3 for the frames perhaps enabling wrapping wouldn't even be that bad. |
|
@jlowin are you okay with me taking this over per the discussion above? or would you prefer to just keep it off? |
|
Totally fine if you want to take over, and also fine with default off as a sane rapid fallback if it doesn't work! @strawgate |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR improves traceback display for narrow terminals by implementing a compressed traceback format. The change creates a dual-handler logging system: one for regular logs and another specifically for tracebacks with reduced visual clutter.
Key Changes:
- Splits logging into two handlers: one for normal logs (excluding tracebacks) and one dedicated to tracebacks
- Configures the traceback handler with compressed formatting (no path/level display) and limits frames to 3 with suppressed framework frames
|
@jlowin updated and should be good to go |
|
Interestingly -- the current state of the PR also seems to improve the performance of printing tracebacks by about 5x (reduce time spent in the richhandler by 80%). In my test setup, printing 20 tracebacks takes 1s on main, 0.2s in this PR and 0.1s with rich tracebacks off See #2053 |
|
I can't submit a review bc it's my own PR but LGTM! |





@strawgate curious if you 👍 . We've had considerably more requests to disable this than enable it :)