[drkonqi] [Bug 248807] Report with a long backtrace can't be sent (bugzilla 65k limit per comment)

[Harald Sitter]

https://bugs.kde.org/show_bug.cgi?id=248807

Harald Sitter <sitter at kde.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Version Fixed In|                            |5.17.0
      Latest Commit|                            |https://commits.kde.org/drk
                   |                            |onqi/c07434bf8e2e6b488c4293
                   |                            |b08c7cb7c56abdf728
             Status|CONFIRMED                   |RESOLVED
         Resolution|---                         |FIXED

--- Comment #17 from Harald Sitter <sitter at kde.org> ---
Git commit c07434bf8e2e6b488c4293b08c7cb7c56abdf728 by Harald Sitter.
Committed on 12/07/2019 at 12:49.
Pushed by sitter into branch 'master'.

prevent exhausting the maximum size of bug reports

Summary:
bugzilla has a hardcoded server-side limit for how large a given comment
may be. this can somewhat easily get triggered by heavily threaded
applications as the backtrace would include a lot of "noise" threads.
when this previously happened drkonqi would find itself incapable of
filing the report and leaving the user to their own devices.

now we are much smarter about this
if the reportinterface finds that the bug description is too long it will
try to use a reduced backtrace (only a couple of lines from the relevant
thread) or when that too is too long to exclude the backtrace entirely.
in both events it would then additionally attach the complete backtrace
to the bug.

for this there's a bunch of rejiggering necessary:
- generateReportFullText has had its signature changed, instead of using
  a lazy bool now use enums to control the output. this should be vastly
  more readable
- new Backtrace control on generateReportFullText ranging Complete>
  Redcued>Exclude
- addedToCC was renamed to attachBacktraceWithReport which is a more
  suitable name for what it does. it's logic has been moved to a new
  attachBacktrace which requires the caller to set the actual comment
- attachBacktrace is called with a full report comment when used via \
  attachBacktraceWithReport (i.e. the user indicated that their crash
  is in fact the same as another report, so their report gets
  attached to the other one). it's called with a simplified message when
  attaching as part of a reduced/excluded backtrace dance

the end result is that the reports can no longer exhaust the hardcoded
character limit.

there is one caveat: the user can still write a super long description
manually and exhaust the limit. this is however very hard to do in
real life without "abusing" the description for something.

CHANGELOG: Bug reporting can no longer exhaust the maximum character size
enforced by Bugzilla
FIXED-IN: 5.17.0

Test Plan:
- file bug report with ETOOLONGTRACE -> gets reduced and attached
- regular attaching still works
- exhausting the limit *exactly* works as expected

Reviewers: #plasma, apol

Reviewed By: apol

Subscribers: plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D22399

M  +2    -1    src/bugzillaintegration/reportassistantdialog.cpp
M  +5    -2    src/bugzillaintegration/reportassistantpages_base.cpp
M  +4    -2    src/bugzillaintegration/reportassistantpages_bugzilla.cpp
M  +76   -15   src/bugzillaintegration/reportinterface.cpp
M  +20   -3    src/bugzillaintegration/reportinterface.h

https://commits.kde.org/drkonqi/c07434bf8e2e6b488c4293b08c7cb7c56abdf728

-- 
You are receiving this mail because:
You are the assignee for the bug.