I see Unknown error 500 when opening pull request
or trying to open file diff
Expected behavior: Pull request is shown
Actual behavior: Error 500
Flakiness? All the time
Ubuntu 16.04, Chrome browser
Hi @mofr
This is a known edge case where reports get corrupted in storage that we have prioritized to investigate.
As a workaround, uploading the report again should fix this.
I seem to be hit by the same (see https://codecov.io/gh/lballabio/QuantLib/commits).
Does a corrupted report affect all further uploads, or might future ones get processed correctly even if I don’t re-upload the lot of them? (It would require re-running CI.)
Hi @lballabio
A bad report will fail the upload, not all uploads for that commit. In this case you appear to be sending us .github/workflows/coverage.yml, can you try adding an ignore rule for this?
That used to work until about a week ago, but yes, I can try that.
Hmm, that didn’t go well (see https://codecov.io/gh/lballabio/QuantLib/commit/5c14f63f17dcf27e254bab9e1674e55acde579e8). I added ".github/**/*" to the ignore section and renamed coverage.yml to codecov.yml for good measure. Do you see anything on your side? Also, is this thread the correct place for me to follow up (because the problem might be the same as the original poster) or should I open a new one? Thanks!
Every 500 is different, probably a new thread, but lets stay here.
I think we timed out trying to process the upload, do you know the rough size? Also, if you are using the bash uploader, can you adding -X fixes, that may help.
Edit: codecov.yml needs to be in the repo root for us to detect and use it, btw. 
Running find . -name *.gcov | xargs wc -l gives me about 1M lines of gcov files. Most of the .gcov files are for system headers; I’ll try pruning them out with -g.
However, my CI uses your github action, not the bash uploader. Not sure how configurable that is?
The codecov.yml with your configuration is in the repo root dir. The one in .github/workflows is the GitHub Actions workflow.
I don’t think you can add that flag to the action. If you can get the uploads down to around 20-50mb, that would be helpful. If not, we may need to switch you out to the bash uploader (the action is a wrapper around it)
I tried a couple of runs locally with the bash uploader, with and without -X fix, and still no joy (here and here). If you see something strange on your side, I’m all ears. On my side, except for these last local tries, the failed commits used the same CI script as in the last successful run. Thanks!
GitHib says either you don’t have access, or the commit doesn’t exist.
commit cc8ebf095db01ad8fcb1a79afcbeefe1bbdab277 seems to timed out again. After trimming what’s the rough size of the upload, do you know? You can add the -d flag to the bash uploader to dump the upload, instead of uploading it for troubleshooting.
If the first one was with -X fixes I would leave that in place and we can investigate why GitHub is giving us access errors.
The one with the access problem - my bad. It was a local try and I ended up uploading the reports before pushing the commit to GitHub.
I’ll try a dump.
The full dump is 28M in full, 27M with -X fix. The version I had uploaded with that commit, though, excluded .gcov files from std headers and was 18M uncompressed.
Hi @lballabio, I realize that it’s been an unacceptable long time hearing from us. I realize that you have since switched off of Codecov, but if you decide to use us again, I think you’ll be satisfied with the infrastructure changes we’ve made to support the large file uploads.
