Project

General

Profile

Bug #9200

Marks with zero similarity participate in 'incompatible' marks

Added by Pavel Andrianov 12 months ago. Updated 11 months ago.

Status:
Closed
Priority:
Immediate
Category:
Bridge
Target version:
Start date:
08/09/2018
Due date:
% Done:

0%

Estimated time:
Detected in build:
svn
Platform:
Published in build:

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.

History

#1

Updated by Evgeny Novikov 12 months ago

  • Priority changed from Normal to Immediate
  • Assignee set to Vladimir Gratinskiy

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.

#2

Updated by Vladimir Gratinskiy 11 months ago

Can't find any action that makes 'incompatible' unsafes from marks with zero similarity.

#3

Updated by Pavel Andrianov 11 months 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.

#4

Updated by Evgeny Novikov 11 months ago

  • Status changed from New to Resolved

This was fixed in "bridge-1.1" as well.

#5

Updated by Vladimir Gratinskiy 11 months 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.

#6

Updated by Evgeny Novikov 11 months 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.

#7

Updated by Pavel Andrianov 11 months 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).

#8

Updated by Evgeny Novikov 11 months 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.

#9

Updated by Evgeny Novikov 11 months 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.

Also available in: Atom PDF