-
Notifications
You must be signed in to change notification settings - Fork 373
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
feat: limit size of the machine string #2385
base: master
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #2385 +/- ##
==========================================
+ Coverage 54.63% 57.33% +2.70%
==========================================
Files 581 597 +16
Lines 77967 84809 +6842
==========================================
+ Hits 42596 48628 +6032
- Misses 32192 32690 +498
- Partials 3179 3491 +312
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
I made this PR primarily with the infinite recursive case in mind. The txtar in #1736 exposes an issue with printing out a massive value. As this PR does nothing to address this, I will close it. My initial idea was to get this merged quickly until #2145 is ready, but I think it will be ready soon and that one will avoid this kind of issue because it is only printing out a trace, not all the values stored in the machine. |
Closes #1981
Currently, it is possible to block machine execution by submitting a transaction that results in an error which produces a massive string due to it stringing together all of the Machine's contents. This PR limits the amount of data that is stringed together. It isn't very useful anyway.
Another solution that was considered
I had experimented with some concurrent solutions to retain the full contents of the string, but while the building of the string was rendered more efficient, the printing of it was not, as expected. A possible solution to this is to write it to a file -- far more performant -- but then there is the issue of these types of logs taking up a lot of disk space if someone continues to submit transactions that produce them.
I am aware that #2145 is a WIP to improve this, but even that does not limit the amount of data printed (I will comment on that PR); it also needs some additional work before it is merged and the intention for this PR is to fix the issue ASAP to avoid this causing a problem during the Challenge Series at Gophercon US.
Here is an example of something that blocks the machine before the changes in this PR are applied. You can run it with and without the changes to compare. Run with
gnokey maketx run
: