Commit details page shows an upload that is currently processing as "unknown error"

[drazisil-codecov]

https://github.com/codecov/gazebo/blob/d980d7145df1d38967eb8fff8c89f82a3725253d/src/pages/CommitDetailPage/CommitCoverage/UploadsCard/Upload.jsx#L89-L95

Since there is not an enum state for "PROCESSING", uploads in this state render with "unknown error"

[eliatcodecov]

It seems like the front end is just not tracking with the ''processing'' state (that should be returned from the api). This is most likely purely a front end fix, but if not we can escalate to the API side of things.

[nicholas-codecov]

Can you provide an example of this occurring?

[drazisil-codecov]

Recreation steps:

• push several coverage uploads.
• see that they show as unknown error while not yet processed

https://app.codecov.io/gh/rustymotors/rusty/commit/0ca7c00d7a185bff8025211332e2f814ebec0d8c

I reuploaded twice...

After a mi or so

And finally

[drazisil-codecov]

And one more run so you can see the "errors"

[nicholas-codecov]

Sorry to ask again, if you wouldn't mind re-running this and grabbing the API responses, there's a whole bunch going on behind the scenes here and without that data, I can't really tell what's going on or why. What I've found so far is that this error message is being triggered here, the data for that erroredUploads comes from here so something about the data being returned from the API is suspicious because we're only ever rendering this when there are uploads that have an error state.

[drazisil-codecov]

@nicholas-codecov

{
                                "node": {
                                    "id": null,
                                    "state": "ERROR",
                                    "provider": null,
                                    "createdAt": "2024-08-02T13:46:38.445277+00:00",
                                    "updatedAt": "2024-08-02T13:46:38.516632+00:00",
                                    "flags": [
                                        "Utils"
                                    ],
                                    "jobCode": null,
                                    "downloadUrl": "https://api.codecov.io/upload/gh/rustymotors/rusty/download?path=v4/raw/2024-08-02/4F87A0A5F48656EE0F18FE2F017AECD6/5117f9bad66c036eceb95f240e023ee78dab7e02/4962b8ff-0dd3-4cc6-b14a-81415b649696/6bba2cbc-41a7-4808-a466-8f65b305c4c6.txt",
                                    "ciUrl": null,
                                    "uploadType": "UPLOADED",
                                    "buildCode": null,
                                    "name": "Utils",
                                    "errors": {
                                        "edges": []
                                    }
                                }
                            },

State appears to be errored, so I guess this is a platform bug.

[katia-sentry]

@trent-codecov, we'll need Platform 👀 on this.

[drazisil-codecov]

Given that most of the values are null, My hunch is that "ERROR" is being set as a defailt value somewhere. Can't find it though. Also, the UploadErrors query returns clean during this time.

[matt-codecov]

the fix described in #1520 will get rid of many (most? all?) "unknown error"s from platform. or at least give us a chokepoint where we can log context around things that slip through other error handling and add new error codes as we discover them so we can propagate more useful messages to the UI

[eliatcodecov]

Just a random thought. If this particular state is usually entered just because Codecov is processing (instead of an error), wouldn't it be better to show a spinner?

In the error case, you'll get something that spins forever (annoying, I know), that results in a support ticket. In the working case, you'll get a spinner that eventually goes away when processing is done -- and no support emails, nor confused users -- which is what we are getting.

The 'broken' path results in a support interaction either way, but by displaying a spinner wouldn't we likely be fielding less of these false positive support tickets and better informing users in general to what's going on?

I know we've battled with correctly rendering a true Processing state for awhile due to how Codecov works under the hood. But making the above switch would likely alleviate confusion for users until we can figure out a truly correct Processing state.

[emreyigit]

I think I have a similar issue here. Reports started to fail suddenly on Codecov 2 months ago without any change on my side. I have applied path fixes; then, it turned to unknown error.

[nikosatwork]

Hi team. Is there an update on this issue? Thank you 🙏

[adrian-codecov]

Closing this after this PR codecov/codecov-api#1061, will reopen if needed