View Issue Details

IDProjectCategoryView StatusLast Update
0022263mantisbtapi soappublic2020-02-04 14:44
ReporterGunSmoker Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
Status newResolutionopen 
Product Version2.0.0 
Summary0022263: Mantis lacks features for automated crash reporting / "exception driven development"
Description

Software developers usually build exception and error reporting facility for their applications. Application should be able to automatically send bug reports for each crash. There must be a central place where all bug reports are collected (e.g. like Mantis), which may be used as TO-DO list for developers to fix bugs.

The idea here is to merge reports about the same crash (from different users) into one bug on Mantis. The more crashes bug receives - the greater priority it will have. So you can fix, say, top 3 bugs in your list - and solve the majority of problems that your users are having.

The problem is that Mantis is not suited for this kind of work. The problems are (*):

  1. There is no way to identify crashes.
  2. There is no way to sort crashes on occurrences.
  3. There is no simple "send bug report" API.

The suggestions are:

  1. Add new property for the bug: "occurrences" / "count". This should be an integer property, which should be 1 on bug's creation and can not be modified by editing bug manually via UI. It should act as normal column in other aspects, be shown in bug's view, "view issues", allow sorting, etc.

  2. Add new property for the bug: "alias" / "bug-id" / "bug-hash". It should be a string, similar to summary, which can be used to identify bugs instead of integer id, with the following properties: a). it must be unique per project; b). attempt to create new bug with existing "alias" should return old bug and increase "occurrences" by 1; c). attempts to enter bugs with alias set must be concurrency-safe; d). exact format of "alias" should not be fixed and left to application. For example, it can be CRC-32 / SHA1 of exception type, address and call stack, or it can be something like "bug_project.exe_module.dll_0x00004567_EAccessViolation".

  3. Add a simplified API to submit bug and attachments in one simple request and get bug description back.

Steps To Reproduce

(*)

Obviosly, you can workaround Mantis problems by:

  1. Using SOAP API;
  2. Introduce custom field to identify crashes;
  3. Introduce custom field to count crashes.

However, there are major problems with this workaround:

  1. Most imprortantly - sorting by integer custom fields is still not working properly in Mantis. That means that you can not identify crashes with most occurrences with just Mantis only. You have to use your own custom SQL.

  2. Second, your submit workflow should be like this: a). find bug by custom field; b). if bug is not found - create new one; c). if bug is found - read it, then edit by adding +1 to occurrences. This obviosly introduces sync issues. If two instances of app from different users will try to submit the same crash simultaneously - you may end up with two bug reports for same crash, or lost occurrences.

  3. Next, your credentials for Mantis will be stored in your application, which means they can be extracted and used. This means that one can potentially do much more than just send a crash report (like read other reports and dev's comments). A new single "send report" API would eliminate this issue.

  4. In older versions of Mantis you could not even search by custom fields - which forced you to use summary as technical non-human readable "alias".

Additional Information

https://blog.codinghorror.com/exception-driven-development/ - more about the described crash reporting idea

http://help.fogcreek.com/the-fogbugz-api/bugzscout - a similar feature in Fogbugz bug tracker. Cases (bugs) about crashes are called "BugzScout cases". "Alias" is called "sScoutDescription", "count" is called "Occurrences". Scout cases can be send via usual fully-featured Fogbugz API or via dedicated "send-report-only" BugzScout API.

http://help.fogcreek.com/7566/bugzscout-for-automatic-crash-reporting - description of BugzScount simplified API.

Bugzilla also have "alias" / "bug-id" / "bug-hash" field (which is called - "alias"). JIRA has "votes" (e.g. "occurrences") and ability to search by most voted issues.

TagsNo tags attached.
Attached Files

Activities

rombert

rombert

2017-01-26 14:06

reporter   ~0055343

It seems to be that you've described ABRT :-)

https://github.com/abrt/abrt

Incidentally, ABRT has MantisBT integration so this should suit your needs.

GunSmoker

GunSmoker

2017-01-26 14:14

reporter   ~0055344

Honestly, Fogbuz suits my needs :)

However, we historically use Mantis.

GunSmoker

GunSmoker

2017-01-26 15:04

reporter   ~0055346

Even if you look at ABRT: https://github.com/abrt/libreport/wiki/MantisBT - you will see that docs says it has problems, because Mantis lacks the mentioned features (unlike Bugzilla), so they have to use workarounds.

GunSmoker

GunSmoker

2017-01-26 15:30

reporter   ~0055347

Screenshots of working feature.

s1.png (90,451 bytes)   
s1.png (90,451 bytes)   
s2.png (74,384 bytes)   
s2.png (74,384 bytes)   
s3.png (11,658 bytes)   
s3.png (11,658 bytes)   
GunSmoker

GunSmoker

2017-01-26 15:41

reporter   ~0055348

https://github.com/mantisbt/mantisbt/pull/1008

GunSmoker

GunSmoker

2017-01-26 15:45

reporter   ~0055349

This can also be integrated with 0022203

GunSmoker

GunSmoker

2020-02-04 14:44

reporter   ~0063581

https://exceptionless.com/exceptionless-api-usage-and-overview/ - a similar feature in Exceptionless bug tracker.

A scoped token allows access only for "post event" API.

Additionally, posting event allows you to specify pre-made "reference id" (a custom ID to view bug report via web), as well as "ManualStackingKey" - for automatic merging same bug reports into one ticket with automatic increase of "Count" (e.g. same as above-discussed "alias", "bug-id", "sScoutDescription"), so you can view unique bug reports only.