https://bugs.kde.org/show_bug.cgi?id=482203
--- Comment #3 from Malte S. Stretz <m...@apache.org> --- I agree that there should be a GUI to manage the crash report queue. The queued reports can be found at ~/.cache/drkonqi/sentry-envelopes/ and the sent items at ~/.cache/drkonqi/sentry-sent-envelopes/ and too clear the queue you can delete the former directory. Since at least on my machine those files are only around 100 kB I don't know if some throttling is really required. Unless maybe you have many of them or a really slow internet connection. It should be possible though to save bandwidth and send the data compressed according to https://develop.sentry.dev/sdk/overview/#request-compression It also looks like the current error handling behaviour could be improved. If I interpret the code correctly then it will try to send all queued files and if one can't be sent due to whatever reason it will keep it in the queue to be picked up by the next run. The files will stick around for 30 days which seems to be a bit excessive. I'd reduce that to 7 days or so and add some logic to avoid resending if the server rejects the payload. I think there are also some issues with the systemd units: The timer is configured to run OnCalendar=hourly which will wake it every hour at the full hour. That's not really an issue for the user but not optimal for the server since it can cause a thundering herd problem. I would change that to OnUnitActiveSec=1 hour RandomizedDelaySec=5 minutes The timer has ConditionPathExistsGlob set. I might be wrong but I think (judging from the output of systemctl --user status drkonqi-sentry-postman.timer) this is evaluated only on unit start time, not on each interval. Ie. when nothing is queued on Plasma session start (when the timer is started) this timer is never executed. Maybe this condition should just be dropped. Then the postman would be executed once per hour but should exit quickly since it doesn't find any files to process. And I think on logon the service is executed twice if any events are queued: Once because of the PartOf=graphical-session.target in the service file and once because the path unit will be triggered. -- You are receiving this mail because: You are watching all bug changes.
