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 more information to crash reports #1816
Comments
That'll be a lot more data than we get now... I'm a bit concerned. Are you speaking of A/B testing etc.? |
This is hard to implement, since it is not always just html which is part of the extraction process. Also it would require massive changes in the backend. ... Im not sure if the outcome would justify the effort. |
I think this would be very useful to be able to fix little nasty bugs that only happen sometimes to some person in some country. |
We needed some more info by some users recently, so I worked on this again. Open a channel page to throw an exception and test the changes: app-debug.apk.zip. As you can see, I added some more functionality. It is mow possible to convert the error reoprt directly to Markdown / HTML which is more user friendly and does not require one to open the incredible bugreport to markdown converter. This should reduce the number of JSON pastes jere on GitHub significantly. I also modified the extractor exceptions to show us the documents or elements which caused problems. Regarding the size problematic:
@theScrabi In the end, this was quite easy and uncomplicated. I just added a |
Nice :D. I like all of this :) Here are some thoughts though: With the ability to open issues directly from NewPipe there might be a chance of user bloating the issues as they might paste without checking. What do you think? |
Maybe there could be a "share" option to open issues with FastHub, with the issue and error report prerendered |
@theScrabi I can add an AlertDialog to make user promise to first search and then create an issue. Something like Please make sure to first search the existing issues and to not just open a new issue. Every new issue requires us to check whether a similar ticket exists to keep the discussion on it bundled in one place. This is time we can spend fixing bugs. So please help us with this.
@Serkan-devel I added the Report error on GitHub button, which opens the share menu when FastHub or any other GitHub clients are installed. But as @theScrabi said, when directing people to create a new issue, they won't check whether one dealing with the problem already exists. As a result there would be tons of new issues which we need to close, but we'd like to spend our time with solving the bugs, not maintaining bug trackers :) |
We could also use this with Sentry, implementing a proper retention policy is long overdue. Right now we're storing years old issues nobody will ever look into any more. I'm not sure how well Sentry is still in use. @ALL can you perhaps tell how you use Sentry and whether you have suggestions in order to allow for using it more efficiently. We collect a lot of data, and my concern is it's too much to overlook, despite having Sentry combine similar reports. |
Exception
Crash log 1
Just took crash report via debug apk, After Installing this apk showing "Leak detected need storage permission,I didn't enable this option. |
@mehedihasanziku Sorry to bother you again, but you need to enable the "Append page content which possibly caused the crash to the error report" switch, so that we can see the page content. Please try to get another crash using the apk above (and enable the switch) and post it directly to #2737. Thanks :-) |
Sometimes we get error reports, but cannot reproduce crashes due to different versions of the parsed website. To get rid of this difficulty, we should make it possible to add the fetched HTML page to the JSON report. I'd suggest to place an additional checkbox at the top/bottom of the report dialog which is not checked by default. If checked, a new element needs to be added at the end of the JSON.
@theScrabi @mauriciocolli @karyogamy @TheAssassin I hope my idea is clear. Is there anything I did not take into account which makes this difficult or not recommendable?
I did not look into this yet, but I guess we need to make some changes in the extractor before we can access the fetched document in the frontend. The changes in the crash report converter are quite simple. However, we might want to add this additional information to Sentry, too.
The text was updated successfully, but these errors were encountered: