[cmd] Fix FP annotations in the case of local-remote diffs #3956
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Source code suppressions seem to work funny (meaning: really buggy) in the context of diffs. An earlier PR, Ericsson#3944 fixed a similar issue in the local-local diff case: we forgot to take source code suppressions into account for the baseline set. The issue is somewhat worse for local-remote and remote-local diffs, as discussed in issue Ericsson#3884. As a feature, this should be comically simple: calculate the set of outstanding reports from the "baseline" and the "new" sets. Suppose these sets are called O(baseline) and O(new). Then, calculating diffs should be this easy: * NEW: O(new) - O(baseline) * RESOLVED: O(baseline) - O(new) * UNRESOLVED: The intersection of O(baseline) and O(new) But, for historical and performance reasons, the way we do this is far, far more convoluted. We use two API calls: `getDiffResultsHash` and `getRunResults`. We use the former call to send the list of bug reports (and more specifically, only the bug hashes of those reports) we have locally to the server, and it returns a set of hashes found on the server, ideally those that would be present in the diff set. We constantly change and adjust these sets of hashes with review status rules, source code suppressions, and after some juggling, we ask for the actual report objects (as opposed to simple hashes) via `getRunResults`. Looking at `get_diff_local_dir_remote_run` in `cmd_line_client.py`, the implementation is super complicated, and its hard to judge whether we truly need this much complexity for something that theoretically so simple. Fixing the specific bug of not handling source code suppressions well could be done, on a high level from two approaches: fixing up the API calls on the server side to not return the the hashes that shouldn't be present in the final result, or patch the client to filter them out. This patch presents the client-only approach. Here is my argument for it. We already branch out for older client versions within (Ericsson#3746), so it would be a chore to fix this for both client versions. You can argue whether fixing this only for later client versions is okay (thats a fair argument), but I think its fair to ask users to upgrade their client if its starts misbehaving. After all, the tool doesn't break, it just work a little funny (meaning: really buggy), which it already does for the local-local case that had to be fixed client side. ANYWAYS. The fix is simple: filter for unreviewed and confirmed reports before calling `getRunResults`. I added new tests for tags just to be sure that it doesn't break anything unrelated, but their behaviour didn't change as a result of this patch.
Szelethus
added
CLI 💻
bruntib
approved these changes
Jul 25, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Source code suppressions seem to work funny (meaning: really buggy) in the context of diffs. An earlier PR, #3944 fixed a similar issue in the local-local diff case: we forgot to take source code suppressions into account for the baseline set.
The issue is somewhat worse for local-remote and remote-local diffs, as discussed in issue #3884.
As a feature, this should be comically simple: calculate the set of outstanding reports from the "baseline" and the "new" sets. Suppose these sets are called O(baseline) and O(new). Then, calculating diffs should be this easy:
But, for historical and performance reasons, the way we do this is far, far more convoluted. We use two API calls:
getDiffResultsHashandgetRunResults.We use the former call to send the list of bug reports (and more specifically, only the bug hashes of those reports) we have locally to the server, and it returns a set of hashes found on the server, ideally those that would be present in the diff set. We constantly change and adjust these sets of hashes with review status rules, source code suppressions, and after some juggling, we ask for the actual report objects (as opposed to simple hashes) via
getRunResults.Looking at
get_diff_local_dir_remote_runincmd_line_client.py, the implementation is super complicated, and its hard to judge whether we truly need this much complexity for something that theoretically so simple.Fixing the specific bug of not handling source code suppressions well could be done, on a high level from two approaches: fixing up the API calls on the server side to not return the the hashes that shouldn't be present in the final result, or patch the client to filter them out.
This patch presents the client-only approach. Here is my argument for it.
We already branch out for older client versions within (#3746), so it would be a chore to fix this for both client versions. You can argue whether fixing this only for later client versions is okay (thats a fair argument), but I think its fair to ask users to upgrade their client if its starts misbehaving. After all, the tool doesn't break, it just work a little funny (meaning: really buggy), which it already does for the local-local case that had to be fixed client side.
ANYWAYS.
The fix is simple: filter for unreviewed and confirmed reports before calling
getRunResults. I added new tests for tags just to be sure that it doesn't break anything unrelated, but their behaviour didn't change as a result of this patch.