Closed whisperity closed 6 years ago
The solution in #72 is a situational hackfix
as discussed in Ericsson/codechecker#356.
Lines like these [1] should be enclosed in some sort of exception wrapping. See @gyorb's explanation in the referenced issue.
@dkrupp, I think we should reopen this issue as it disuccess a deeper underlying problem.
the whole thing was rewritten now...
There are certain cases when Thrift starts to generate heavy
COMMUNICATION_ERROR
s.Cases
There might be more causes, these are just the list of those discovered so far!
It seems like that all these issues boil down to the fact that the codes calling Thrift assumes that
These are all assumptions that are NOT invariant to every project, so these assumptions should be eliminated from the code. In the event these conditions do not hold true, access to the server should not be sent.
Maybe it's an issue with CodeChecker itself, that it does not respond in an orderly fashion when I try to get results for something nonexistent? I'm summoning @gyorb and @Xazax-hun to this discussion.
Example
The exceptions look something like this: