Community
Participate
Working Groups
I'm not sure if my understanding of incidents and problems is correct but I observed something strange worth reporting to get clarification if that's expected. While reviewing Platform problems it turned out that some incidents seem to be "collapsed" to wrong problems. Example: The following problem [1] contains a comment from this incident [2] which would mean to me as another incident of the problem tracked in [1]. This would mean that both [1] and [2] contain the same stack trace. But when looking at the stack trace of [2] it looks different than the stack trace in [1] and also the exception thrown is different. Is this expected? What is the meaning of "incident" and "problem" if incident of a problem may have different stack trace than the problem? Thanks a lot for clarification! [1] https://dev.eclipse.org/recommenders/committers/confess/#/problems/54c4eeb3bee810030da05f1e/details [2] https://dev.eclipse.org/recommenders/committers/confess/#/incidents/55a014dfe4b0cf2e4bf590de
This particular case is a bug. It seems that under some conditions the "is the same exception" check is not executed. Will investigate.
(In reply to Marcel Bruch from comment #1) > This particular case is a bug. It seems that under some conditions the "is > the same exception" check is not executed. Will investigate. Thanks! Will it be possible to re-run grouping incidents into correct problems when the bug is fixed? The incident mentioned in comment 0 is bug 427421 which we were never able to reproduce so it would be good to have the right group of users able to reproduce it. I would have never found it if the message from reporter did not appear on the problem page despite the fact it is not the right problem.
FYI: I see why this happens. There are different duplication detection rules that apply: Some say 'no duplicate', and one says 'yes it's a duplicate'. While obviously wrong in this case, the same rule is required for other incidents. I need to provide some additional logic, which rule can be applied when. This is unfortunately not a trivial fix and needs to be validated against all existing mappings . Please don't expect a fast fix.
(In reply to Marcel Bruch from comment #3) > I need to provide some additional logic, which rule can be applied when. > This is unfortunately not a trivial fix and needs to be validated against > all existing mappings . Please don't expect a fast fix. OK, thanks!
I run the duplicate detection on the whole database this weekend. The problem referenced above looks okay now. I'm closing this bug. In case you experience another other strange grouping, please create a new bug report with the problem and incident URL as you did here. This helps me a lot to create new test cases for yet unexpected data formats. Tiny fun fact: We got 400K error reports but 220K different stack traces (incl. line numbers). O_o #FunWithDuplicateDetection
