-
Notifications
You must be signed in to change notification settings - Fork 43
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
Remove backtrace #1464
Remove backtrace #1464
Conversation
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.
I also have never found this to be too useful, but I'm curious if maybe @graydon had some uses in mind.
Hmm, I think I would like to keep them but it's only a mild preference. I think I mostly only see/use them when debugging test failures in the soroban host, and even then I fairly often want to look around, so set breakpoints in the IDE debugger. I won't block this if you both feel like they're not pulling their weight (and especially if users never get any value out of them, I'm certain we added them primarily for user benefit). Are you sure all/most scenarios users get a test-runner panic it'll have sufficient user-contract context in it? |
As far as I can tell I haven't seen a case where I didn't otherwise have a backtrace available. Iirc we built the back tracing first, and then later added really good error handling and propogation to panics, (I think you did both! Thanks!!!), and so it's possible we just made the existing back tracing redundant. Another way I could change this proposal is keep the backtrace, and only output it in the debug fmt if an env var is set, such as |
I think I would prefer that, yes. Again, not a super-duper preference but, for example, in core we've repeatedly spent person-months to try to even get backtraces reliably reporting (the C++ library often fights with them amazingly) to debug field issues, I'd like to keep the ability close-ish at hand if it's not a huge burden. |
This reverts commit 6ce8e01.
I've pushed an update putting backtrace behind a new feature flag. I think this has the best tradeoffs because of the dep graph, as it'll remove the dep graph from contract developers. |
What
Moved backtrace in the Host's DebugInfo behind a new feature.
Why
The backtrace output is included in the Debug formatting of errors when testutils are enabled, but the trace has not turned out to be that useful in contract tests written with the SDK.
When an error occurs in a contract test the output includes two long stack traces. The first is the one provided by backtrace. The second is one provided by the Rust test harness. Both are very similar and contain approximately the same information. The Rust test harness' trace is actually a little easier to read because it's not quite so verbose.
Here's a before and after of what a test failing looks like before and after this change:
Before
After
Note
I'm not attached to this change if we need back traces for something, but if we need to keep them, I'm interested in how we can silence them for errors in contract tests.
Bonuses
As a bonus, this removes 7 deps from the dep graph for contract developers! 🎉