Strange Codecov API `diff` totals returned

Support Bug Fixes
1

I am mining a few open source repositories and I am using the Codecov API to retrieve the patch coverage but I noted some rather interesting results in the response and in the web UI. I have three cases in particular that are of interest

  1. Null Diff object
{
    "commitid": "b9c22565fe0ee270f434a982802fa489ea075c1e",
    "message": "Javadoc",
    "timestamp": "2022-11-06T16:42:00Z",
    "ci_passed": null,
    "author": {
        "service": "github",
        "username": "garydgregory",
        "name": null
    },
    "branch": "master",
    "totals": {
        "files": 289,
        "lines": 13453,
        "hits": 10913,
        "misses": 1939,
        "partials": 601,
        "coverage": 81.12,
        "branches": 1980,
        "methods": 3304,
        "sessions": 1,
        "complexity": 4601.0,
        "complexity_total": 5624.0,
        "complexity_ratio": 81.81,
        "diff": null
    },
    "state": "complete",
...
}

The corresponding view from the web UI is:
processing_with_Null

As can be seen from the picture, the status is processing and the UI shows the patch coverage of 24%, I would’ve expected this to return an array diff like "diff": [ ..., "24.00", ... ] not a "diff": null. you can view the response https://codecov.io/api/v2/gh/apache/repos/commons-collections/commits/b9c22565fe0ee270f434a982802fa489ea075c1e .

  1. Null Patch Coverage
    The second case is where the UI shows the patch coverage but the API returns a patch diff array property but the index corresponding to the patch is null and the status is ci_passed .
{
    "commitid": "cfd5b6e56792a5143bc305832b674448b70be1d0",
    "message": "Bump actions/setup-java from 3.6.0 to 3.7.0 #126",
    "timestamp": "2022-12-02T03:02:23Z",
    "ci_passed": true,
    "author": {
        "service": "github",
        "username": "garydgregory",
        "name": null
    },
    "branch": "master",
    "totals": {
        "files": 288,
        "lines": 13424,
        "hits": 10900,
        "misses": 1932,
        "partials": 592,
        "coverage": 81.2,
        "branches": 1982,
        "methods": 3294,
        "sessions": 1,
        "complexity": 4604.0,
        "complexity_total": 5621.0,
        "complexity_ratio": 81.91,
        "diff": [
            0,
            0,
            0,
            0,
            0,
            null,
            0,
            0,
            0,
            0,
            null,
            null,
            0
        ]
    },
    "state": "complete"
...
}

The corresponding Web UI can is:
diff_but_null
The API can be viewed here https://codecov.io/api/v2/gh/apache/repos/commons-collections/commits/cfd5b6e56792a5143bc305832b674448b70be1d0
Again the expected reponse would’ve been "diff": [..., "100.00",...]
3. Zero diff
The last case is when the api returns something like:

{
    ...
    "branch": "master",
    "totals": {
        "files": xxx,
        "lines": xxx,
        "hits": xxx,
        "misses": xxx,
        "partials": xxx,
        "coverage": xxx,
        "branches": xxx,
        "methods": xxx,
        "sessions": xxx,
        "complexity": xxxx,
        "complexity_total": xxx,
        "complexity_ratio": xxx,
        "diff": 0,
...
}

I don’t have an actual example but it something I have encountered.

Question

  1. What causes the API to return a response like these (Scenario 1, 2 and 3)?
  2. I noted a number of status processing, shouldn’t codecov time-out after some time?
    a) I noted as well that builds with processing status are often followed by builds that actually complete and the previous builds get stuck in processing phase forever. What could be the cause for this?

I read through some of discussions somewhat related to this but I cannot conclusively say they answer the above question. Two of discussions can be found Issue 1 and Issue 2 .

The Github repo I am using as an example is: apache commons-collections codecov and apache commons-collections repo

2

@ErnestFistozz there is a lot to sift through here, I’ll try to get you some answers

3

@ErnestFistozz sorry for the delay here. We’re digging into this and seeing why you’re getting the difference.

4

I forgot to mention @ErnestFistozz this should be resolved now.