Since all the necessary information has been included, we’ve flagged this for attention by an expert. This means that somebody will look at your report, maybe ask some follow-up questions, and try and determine if it’s really a false-positive that should be fixed.
This review could be done hours, days, or even weeks from now. If it takes a while – it doesn’t mean your report isn’t important to us, it just means that our teams are already hard-at-work developing new language analysis features, and your report is in the queue.
If you’re using SonarQube or SonarCloud – an issue administrator can always mark an issue as a false-positive in the UI (this also suppresses it in SonarLint when using Connected Mode). The rule can also be disabled in your Quality Profile if it’s particularly noisy.
Yes I’ve marked the issue as a falsepositive in our SQ environment.
The rule itself is not that noisy, because we mostly stick with 127 ranges in unittests, which are correctly excluded. But in this particular test I needed more test IPs.
indeed, this is not the expected behavior. It seems we removed the two addresses from the exception logic the last time we touched the rule. I created a ticket to address the false positives.
,