Bug #9200
closedMarks with zero similarity participate in 'incompatible' marks
0%
Description
Marks with zero similarity are considered, when 'incompatible marks' are calculated. Such marks are hidden by default at error trace page, so it is difficult to find and resolve the conflict. The idea is not to consider such marks at all. The idea for future is to somehow configure the limit of similarity, when the mark can be applied.
Updated by Evgeny Novikov over 6 years ago
- Assignee set to Vladimir Gratinskiy
- Priority changed from Normal to Immediate
There is another issue for the similarity limit. Here it is just required to avoid incompatible marks when similarities are 0. I suggest to still show these marks in various statistics by default as well as to show them after adopting a corresponding filter in views.
Updated by Vladimir Gratinskiy over 6 years ago
Can't find any action that makes 'incompatible' unsafes from marks with zero similarity.
Updated by Pavel Andrianov over 6 years ago
What do you mean by 'action'? If you have one mark 'bug' for an error trace with 100% similarity and one mark 'false unsafe' with 0% similarity, the result is 'incompatible marks'. I suggest not to consider zero-similarity marks for incompatibility. Anyway, let them stay at various statistics.
Updated by Evgeny Novikov over 6 years ago
- Status changed from New to Resolved
This was fixed in "bridge-1.1" as well.
Updated by Vladimir Gratinskiy over 6 years ago
Evgeny Novikov wrote:
This was fixed in "bridge-1.1" as well.
I'm not sure about that. Currently I'm trying to find what action (create mark/change mark/upload report, etc.) could lead to the bug.
Updated by Evgeny Novikov over 6 years ago
Vladimir Gratinskiy wrote:
Evgeny Novikov wrote:
This was fixed in "bridge-1.1" as well.
I'm not sure about that. Currently I'm trying to find what action (create mark/change mark/upload report, etc.) could lead to the bug.
It was enough to create 2 marks with different verdicts, one of which should have 0 similarity, another one >0 similarity. Other issues if so should be considered separately.
Updated by Pavel Andrianov over 6 years ago
- Status changed from Resolved to Open
The case is still present. We can not reproduce it, so here is one more link http://10.10.18.221:8998/reports/unsafe/5f10b811a211597f29b842cdb36cceca/. Note, there are other similar unsafes (see 'incompatible marks' view).
Updated by Evgeny Novikov about 6 years ago
- Status changed from Open to Resolved
It turned out that one needs to recalculate caches through the manager tools to get rid of the issue.
Updated by Evgeny Novikov about 6 years ago
- Status changed from Resolved to Closed
As both automatic and manual tests passed, I merged the branch to master in 1c078402e. Don't forget to recalculate caches for unsafe marks through the manager tools.