That wouldn’t account for what we see, because prior to the second analysis, we commit code changes. So in the second analysis the SCM would report a date newer than both the initial analysis data and changed lines. We don’t analyze the same, unchanged code multiple times.
BTW, I’ve just today started using SLBs in our builds. It required us to retrieve the
new_coverage metric via the SQ API and then to fail the build if it reports less than our minimum requirement. So this is no longer a problem for us. If SLBs ever enforce a new coverage quality gate, we can remove our workaround.