[bugfix] Old client has different behavior with new server #3746
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
bruntib
force-pushed
the
fix_diff_command
branch
from
78ad375
to
f732b87
Compare
This getDiffResultsHash() function is returning a set of reports based on what are they compared to in a "CodeChecker cmd diff" command. Earlier this function didn't consider false positive and intentional reports as closed reports. The client's behavior also changed from CodeChecker 6.20.0 and this behavior is adapted to the new server behavior. The problem is that the old client works correcly only with the old server. For this reason we are branching based on the client's version.
bruntib
force-pushed
the
fix_diff_command
branch
from
f732b87
to
f6d0fed
Compare
dkrupp
approved these changes
Sep 19, 2022
| .filter( | ||
| .outerjoin(File, Report.file_id == File.id) | ||
|
|
||
| if minor >= 50: |
There was a problem hiding this comment.
Also please check for the major version too.
Should be >=6
| Report.fixed_at.isnot(None))) | ||
| results = session.query(Report.bug_id) | ||
|
|
||
| if minor >= 50: |
| .filter(Report.fixed_at.is_(None)) | ||
| .filter(Report.bug_id.in_(report_hashes)) | ||
|
|
||
| if minor >= 50: |
Szelethus
added a commit
to Szelethus/codechecker
that referenced
this pull request
Jul 13, 2023
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.
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.
This getDiffResultsHash() function is returning a set of reports based on what are they compared to in a "CodeChecker cmd diff" command. Earlier this function didn't consider false positive and intentional reports as closed reports. The client's behavior also changed from CodeChecker 6.20.0 and this behavior is adapted to the new server behavior. The problem is that the old client works correcly only with the old server. For this reason we are branching based on the client's version.